Conversation
Bump .cudaq_version to the CUDA-Q 0.16.0 release tag commit
(51671baac373c545c9651c3cfa1a8d371aa67ec7).
The from-source Algorithms lanes failed at pytest with
'No module named cudaq' even though the CUDA-Q build succeeded and
installed cudaq/__init__.py at the /cudaq-install prefix root. The
'Run tests' step in lib_algorithms.yaml has no explicit shell, and
inside the cuda-quantum devcontainer the runner's default resolves to
sh (dash). Its 'if [[ "${{ inputs.cudaq_source }}" == "source" ]]'
condition fails under dash ('[[: not found'), and a failing command in
an if condition does not trip 'sh -e' — so the step silently took the
else branch and ran the test script with --pip-cudaq, which leaves the
source build off PYTHONPATH. The 'Configure' step's cache_key_suffix
[[ test has the same latent problem.
Set a workflow-level 'defaults: run: shell: bash' so every plain run
step in this workflow gets bash (the container has it; the composite
actions already use it explicitly).
Signed-off-by: Scott Thornton <wsttiger@gmail.com>
wsttiger
force-pushed
the
fix/source_lane_016_pin
branch
from
September 14, 2026 22:57
c37b8f2 to
36635f7
Compare
A .cudaq_version change makes pr_workflow invoke lib_algorithms twice in one run (pip lanes + pin-triggered source lanes) and wheel_algorithms in both PyPI and Custom modes. Both reusable workflows keyed their concurrency group on github.ref alone, so the second invocation cancelled the first — the source and pip Algorithms lanes kept cancelling each other on this PR. Add the source/mode input to each group so the concurrent invocations are distinct. Signed-off-by: Scott Thornton <wsttiger@gmail.com>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Follow-up to #50, carrying the
.cudaq_versionbump that was split outof it — together with the fix for what its first run caught.
The bug (pre-existing since #42, first exercised by #50's pin
change): the
Run testsstep inlib_algorithms.yamlbranches onif [[ "$cudaq_source" == "source" ]], but the step has noshell:and resolves to
sh(dash) inside the CI container — where[[doesnot exist. The failed condition silently took the pip branch
(
--pip-cudaq, which deliberately puts no source install onPYTHONPATHand whose pip install is gated to pip lanes), producingModuleNotFoundError: No module named 'cudaq'on all four sourcelanes. The masking was perfect on ordinary PRs: for pip lanes the
broken conditional happens to take the correct branch. Evidence: the
run log shows
shell: sh -e {0}and[[: not foundone line beforethe import error; the CUDA-Q 0.16.0 build itself succeeded and
installed
cudaq/__init__.pyexactly where--cudaq-prefixlooks.The fix: a workflow-level
defaults: run: shell: bashonlib_algorithms.yaml(with a comment on the dash hazard), coveringthis step and the same latent issue in the Configure step.
The pin:
.cudaq_versionmoves to the 0.16.0 release tag commit(
51671baa), so this PR's own CI fires the from-source lanes throughthe repaired conditional — building the released source (the build
from #50's run is already cached under the matching key) and running
the suite against it. That run is the validation.
Update (commit 638e76d): the pin change also surfaced a second
latent bug — both reusable build workflows keyed their concurrency
group on
github.refalone, so whenpr_workflowinvokeslib_algorithmstwice in one run (pip + source lanes) the secondinvocation cancelled the first (visible as the Algorithms lanes
repeatedly cancelling). Fixed by scoping the group with the
cudaq_source/cudaq_wheelsinput. Two-for-one: the source laneswere designed to catch exactly this class of "only shows up when the
pin moves" breakage.