CI: switch the install script to git clone#92
Closed
malberts wants to merge 2 commits into
Closed
Conversation
GitHub recently converted older MediaWiki release refs (REL1_39 through
REL1_42, plus all old extension/skin branches down to REL1_20) from
branches to tags, leaving both refs in place under the same name. The
bare `archive/<name>.tar.gz` URL form now returns HTTP 300 Multiple
Choices for those names instead of a tarball:
the given path has multiple possibilities:
#<Git::Ref:...>, #<Git::Ref:...>
The matrix only covers REL1_43+ so this isn't surfacing today, but the
bare URL form is a latent hazard as future versions move through the
same conversion. Switching to `git clone --depth 1 --branch <name>`
resolves either ref form transparently and is robust to whatever
Wikimedia does with the refs next.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
MediaWiki marks phpunit.xml.template with `export-ignore` in `.gitattributes`, which excludes it from `git archive` output (and therefore from GitHub's `archive/<ref>.tar.gz` tarball endpoint). That's why the new-runner code path had to fetch it separately, and why the existing inline TODO anticipated this cleanup. `git clone` does not honour `export-ignore`; the file is in the working tree after a normal checkout. With installWiki.sh now using `git clone`, the separate wget for the template becomes dead code. Drop it. Bump the cache key to invalidate existing wget-era entries (which lack `phpunit.xml.template` because they were populated from the archive tarball); without the bump, on every cache hit the file would be absent and `composer phpunit:config` would fail. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
malberts
force-pushed
the
ci/install-modernize-rel
branch
from
80ec252 to
d7d5eec
Compare
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
1 participant
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.
Mirrors the equivalent change being applied to the
masterbranch.masterandrelare byte-identical lockstep; CI changes need to land on both.The current matrix covers REL1_43+, none of which is in the affected range, so this isn't fixing a current breakage. It removes a latent hazard as future MediaWiki versions move through the same branch-to-tag conversion, and realises the inline TODO that already predicted dropping the
phpunit.xml.templatewget.Switch the install script to
git cloneWikimedia recently converted older MediaWiki release refs (REL1_39 through REL1_42, plus older extension/skin branches) from branches to tags. The original branch refs still exist for now, so the same names resolve as both a branch AND a tag. GitHub's archive endpoint can no longer disambiguate the bare
archive/<name>.tar.gzURL form in that state, and returns an HTTP 300 Multiple Choices with a 105-byte body:Switching
installWiki.shtogit clone --depth 1 --branch <name>resolves whichever ref form exists and is robust to whatever Wikimedia does with the refs next.Drop the redundant wget for
phpunit.xml.templateThe new-runner code path was fetching
phpunit.xml.templatefromraw.githubusercontent.combecause MediaWiki marks the fileexport-ignorein.gitattributes, which excludes it fromgit archiveoutput.git clonedoes not honourexport-ignore; the file is in the working tree after a normal checkout. WithinstallWiki.shnow usinggit clone, the separate wget becomes dead code. This realises the inline TODO already noting "remove this once installWiki.sh switches togit clone".Bump the cache key
Existing wget-era cache entries lack
phpunit.xml.templatebecause they were populated from the archive tarball. Without a key bump, on every cache hit after merge the file would be absent andcomposer phpunit:configwould fail. Bump to-v2so the next run produces a fresh entry from thegit clonepath, with the file included.