In templates/yml/base_ci_workflow.yml.gsl the dependency checkout steps reference steps.get-branch.outputs.branch_name, but the get-branch step writes its output as branch:
# get-branch (lines 356/358, likewise 523/525)
echo "branch=${{ github.head_ref }}" >> $GITHUB_OUTPUT
# dependency checkout (lines 374/536)
ref: ${{ steps.get-branch.outputs.branch_name }}branch_name is not defined anywhere in the template, so the expression evaluates empty and actions/checkout silently falls back to each dependency's default branch. Both job macros carry the pair, and the generated workflows in all repositories propagate it. Introduced with the owner-repositories change (8d79aea).
Effect: dependency checkouts never resolve a matching branch name. A push to a version branch builds against master dependencies rather than the corresponding version branches, and a pull request whose topic branch exists in the owner's dependency repositories still builds against their defaults.
One note on the correction: substituting branch alone would fail any build whose branch does not exist in a dependency repository — actions/checkout errors on a nonexistent ref rather than falling back — and the current empty-ref fallback is what keeps ordinary pull requests building. If the intent is match-else-default, branch resolution needs an existence check per dependency (e.g. git ls-remote --heads) before emitting the ref.
Happy to submit the template change if useful.
In
templates/yml/base_ci_workflow.yml.gslthe dependency checkout steps referencesteps.get-branch.outputs.branch_name, but theget-branchstep writes its output asbranch:branch_nameis not defined anywhere in the template, so the expression evaluates empty and actions/checkout silently falls back to each dependency's default branch. Both job macros carry the pair, and the generated workflows in all repositories propagate it. Introduced with the owner-repositories change (8d79aea).Effect: dependency checkouts never resolve a matching branch name. A push to a version branch builds against master dependencies rather than the corresponding version branches, and a pull request whose topic branch exists in the owner's dependency repositories still builds against their defaults.
One note on the correction: substituting
branchalone would fail any build whose branch does not exist in a dependency repository — actions/checkout errors on a nonexistent ref rather than falling back — and the current empty-ref fallback is what keeps ordinary pull requests building. If the intent is match-else-default, branch resolution needs an existence check per dependency (e.g.git ls-remote --heads) before emitting the ref.Happy to submit the template change if useful.