CI: switch the install script to git clone#496
Merged
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 5.x matrix includes REL1_39, REL1_41, REL1_42, currently passing
only because the install step is gated on a cache hit and the cache
entries pre-date the conversion. Cache eviction would tip those rows
red. 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. `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 from -v20 to -v21 so existing wget-era cache entries (which lack `phpunit.xml.template` because they were populated from the archive tarball) do not satisfy the new code path. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
82712f4 to
3bab406
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
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.
Fixes latent install-script bitrot affecting REL1_39, REL1_41, and REL1_42, and drops the now-redundant wget for
phpunit.xml.template.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:The matrix's REL1_39, REL1_41, and REL1_42 rows are currently passing only because the install step is gated on a cache hit, and the cached MediaWiki trees were populated from the pre-conversion wget era. Cache eviction (7-day inactivity on a given key, or the cache-key bump in this PR) would tip them red. 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 (1.46+) was fetching
phpunit.xml.templatefromraw.githubusercontent.combecause MediaWiki marks the fileexport-ignorein.gitattributes, which excludes it fromgit archiveoutput (and therefore from GitHub'sarchive/<ref>.tar.gztarball endpoint).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.Bump the cache key
Existing wget-era cache entries (
-v20) lackphpunit.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-v21so the next run on each cache key produces a fresh entry from thegit clonepath, with the file included.