Fix base-branch and composer-alias resolution#1056
Merged
Conversation
The "Compute base branch" step in module-ci.yml was testing the v##-branch regex against $BRANCH_NAME, which resolves to github.head_ref on PRs (the source branch). For a feature PR targeting a v##-branch, this fell through to BASE_BRANCH=master and the skeleton fallback installed the wrong version of Altis. Switch the regex to a new $BASE_REF env var sourced from github.base_ref || github.ref_name (target on PRs, pushed branch on push events), matching how travis/module.yml derived BASE_BRANCH from $TRAVIS_BRANCH. Also add developer-side test scripts under .github/workflows/tests/ that mirror the inline branch and version resolution shell snippets, so the logic can be exercised locally without round-tripping through GitHub Actions. Each test file cross-references its YAML counterpart to flag drift on review. Update workflows/README.md to document the new test scripts and to correct the base-branch fallback description (the prior text still said dev-master from before #1055, and "trigger ref" rather than the PR target ref). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
PR #1055 changed the alias for `dev-*` installed versions from the version itself (matching Travis's `/^dev/q` short-circuit) to a flat `9999.9.9`. That breaks any sibling whose constraint on the package under test is a literal `dev-master` (or similar): the alias `9999.9.9` only satisfies numeric constraints, so a `dev-master` constraint fails to resolve. altis/dev-tools is the most exposed example — most altis modules require it as `dev-master`, so dev-tools' own CI on a feature branch fails with "X dev-master requires altis/dev-tools dev-master -> conflicts with your root composer.json require (dev-feat as 9999.9.9)". Restore the Travis-equivalent behaviour: - empty installed_version -> alias=9999.9.9 (sensible fallback) - dev-* installed_version -> alias=$INSTALLED_VERSION (e.g. dev-master) - concrete X.Y.Z -> alias=X.Y.Z9 Update ci-version-resolution.sh to match. Also flip the dev-tools self-CI caller to the relative-path form `./.github/workflows/module-ci.yml`. Without this, this PR's CI runs master's copy of the reusable workflow and so does not exercise the workflow change under review. Module repos that consume module-ci.yml continue to pin to a SHA in their own ci.yml. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
jerico
approved these changes
May 9, 2026
|
Backport failed for Please cherry-pick the changes locally and resolve any conflicts. git fetch origin v12-branch
git worktree add -d .worktree/backport-1056-to-v12-branch origin/v12-branch
cd .worktree/backport-1056-to-v12-branch
git switch --create backport-1056-to-v12-branch
git cherry-pick -x 56ccfbf12b18709088e1e0f3890c0d21f0132e8c 55c1a717d75bfe08ef4c8a634ea526b538d25135 |
|
Backport failed for Please cherry-pick the changes locally and resolve any conflicts. git fetch origin v26-branch
git worktree add -d .worktree/backport-1056-to-v26-branch origin/v26-branch
cd .worktree/backport-1056-to-v26-branch
git switch --create backport-1056-to-v26-branch
git cherry-pick -x 56ccfbf12b18709088e1e0f3890c0d21f0132e8c 55c1a717d75bfe08ef4c8a634ea526b538d25135 |
After resolving conflicts, continue with:# Add the resolved files
git add .
# Continue the cherry-pick
git cherry-pick --continue
# Push the branch to GitHub
git push --set-upstream origin backport-1056-to-v12-branch
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktree/backport-1056-to-v12-branchThen create a pull request using the GitHub CLI: gh pr create --base v12-branch --head backport-1056-to-v12-branch --title "[Backport v12-branch] Fix base-branch and composer-alias resolution" --body "Backport of #1056 to \`v12-branch\`." |
|
Backport failed for Please cherry-pick the changes locally and resolve any conflicts. git fetch origin v12-branch
git worktree add -d .worktree/backport-1056-to-v12-branch origin/v12-branch
cd .worktree/backport-1056-to-v12-branch
git switch --create backport-1056-to-v12-branch
git cherry-pick -x 56ccfbf12b18709088e1e0f3890c0d21f0132e8c 55c1a717d75bfe08ef4c8a634ea526b538d25135 |
|
Backport failed for Please cherry-pick the changes locally and resolve any conflicts. git fetch origin v26-branch
git worktree add -d .worktree/backport-1056-to-v26-branch origin/v26-branch
cd .worktree/backport-1056-to-v26-branch
git switch --create backport-1056-to-v26-branch
git cherry-pick -x 56ccfbf12b18709088e1e0f3890c0d21f0132e8c 55c1a717d75bfe08ef4c8a634ea526b538d25135 |
After resolving conflicts, continue with:# Add the resolved files
git add .
# Continue the cherry-pick
git cherry-pick --continue
# Push the branch to GitHub
git push --set-upstream origin backport-1056-to-v12-branch
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktree/backport-1056-to-v12-branchThen create a pull request using the GitHub CLI: gh pr create --base v12-branch --head backport-1056-to-v12-branch --title "[Backport v12-branch] Fix base-branch and composer-alias resolution" --body "Backport of #1056 to \`v12-branch\`." |
2 tasks
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
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.
Following on from #1055, there were still a couple of edge cases in the module CI workflow worth tightening up before module repos start consuming the reusable workflow at scale: the branch-resolution regex was being tested against the wrong ref on PRs (so feature PRs targeting a
v##-branchfell back to amasterskeleton), and the new composer alias produced9999.9.9fordev-*installed versions, which doesn't satisfy adev-masterconstraint from sibling packages. This PR fixes both, adds developer-side test scripts that mirror the inline shell logic, and flips the dev-tools self-CI caller to a relative-path reference so workflow changes are exercised by their own PRs.Summary
v##-branchregex against the PR target ref (github.base_ref) instead of the source ref. Previously a feature PR against av##-branchresolvedBASE_BRANCH=masterand the skeleton fallback installed master-version Altis.dev-*installed versions, alias to the installed version itself instead of9999.9.9. The9999.9.9alias only satisfies numeric constraints and breaks sibling packages that require this package asdev-master. Travis handled this correctly via its/^dev/qsed short-circuit; this restores that behaviour while keeping Update branch name and version resolution #1055'spackages-devlookup and missing-package fallback..github/workflows/ci.yml) to the relative-path form./.github/workflows/module-ci.yml, so this repo always tests the workflow at the PR commit instead of master's copy. Without this, workflow changes here aren't exercised by their own PR..github/workflows/tests/mirroring both inline shell snippets, runnable locally.workflows/README.mdto document the test scripts and correct the base-branch fallback description.Why
Branch resolution
Travis derived
BASE_BRANCHfrom$TRAVIS_BRANCH(the PR target on PRs);github.head_ref(used byBRANCH_NAME) is the source on PRs, so the GHA equivalent isgithub.base_ref.mastermastermasterv##-branchv##-branchv##-branchfeat/*->mastermastermasterfeat/*->v##-branchmaster(BUG)v##-branchComposer alias
The dev-tools self-CI run on this PR initially failed with:
PR #1055 changed the alias logic so any
dev-*installed version produced9999.9.9, but Travis emitted the literal version (e.g.dev-master). For dev-tools — which most altis modules require asdev-master— the9999.9.9alias doesn't satisfy that constraint and resolution fails. The fix:INSTALLED_VERSION9999.9.9(sensible fallback)dev-*$INSTALLED_VERSION(e.g.dev-master)X.Y.ZX.Y.Z9Test scripts
Both live under
.github/workflows/tests/and ship as developer-side tools (not wired into CI for now). Each has a full matrix and an--evalmode for ad-hoc input. See.github/workflows/README.mdfor usage.ci-branch-resolution.sh— 9 cases covering pushes and PRs acrossmaster,v##-branch, slashy source names, and a non-matching target.ci-version-resolution.sh— 10 cases covering concrete versions in.packages/.packages-dev, missing packages,dev-*versions, prerelease suffixes, duplicates, and exact-name matching.Test plan
.github/workflows/tests/ci-branch-resolution.sh(9 passed, 0 failed).github/workflows/tests/ci-version-resolution.sh(10 passed, 0 failed)altis-local-server) targeting av##-branchonce the SHA is bumped🤖 Generated with Claude Code