ci(osx): use new location of the perforce cask#209
Merged
derrickstolee merged 1 commit intoOct 18, 2019
Conversation
The CI builds are failing for Mac OS X due to a change in the
location of the perforce cask. The command outputs the following
error:
+ brew install caskroom/cask/perforce
Error: caskroom/cask was moved. Tap homebrew/cask-cask instead.
So let's try to call `brew cask install perforce` first (which is what
that error message suggests, in a most round-about way).
The "caskroom" way was added in 672f51c (travis-ci:
fix Perforce install on macOS, 2017-01-22) and the justification
is that the call "brew cask install perforce" can fail due to a checksum
mismatch: the recipe simply downloads the official Perforce distro, and
whenever that is updated, the recipe needs to be updated, too.
CI servers are typically fresh virtual machines, but not always. To
accommodate for that, let's try harder if `brew cask install perforce`
fails, by specifically pulling the latest `master` of the
`homebrew-cask` repository.
This will still fail, of course, when `homebrew-cask` falls behind
Perforce's release schedule. But once it is updated, we can now simply
re-run the failed jobs and they will pick up that update.
As for updating `homebrew-cask`: the beginnings of automating this in
https://dev.azure.com/gitgitgadget/git/_build?definitionId=11&_a=summary
will be finished once the next Perforce upgrade comes around.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
wilbaker
approved these changes
Oct 17, 2019
dscho
approved these changes
Oct 18, 2019
dscho
added a commit
that referenced
this pull request
May 12, 2026
…uild The previous version of this commit wrote `$BUILD_VERSION` into a `version` file at the root of the Windows worktree, on the assumption that GIT-VERSION-GEN inside the mingw-w64-git build would pick it up the same way the macOS and Linux jobs do. It does not, and the file was silently ignored. Pipeline run #209 made that obvious: the artifacts came out named after `v2.53.0.vfs.0.10.20260512065248`, with the timestamp tail that please.sh's fallback synthesises, even though the prereqs stage's `$(git_version)` was the static `9.99.99.vfs.0.0` set by the TO-DROP debug commit. Re-reading `please.sh`'s `build_mingw_w64_git`, the actual sequence is: 1. `git for-each-ref --count=1 --sort=-taggerdate --points-at=HEAD 'refs/tags/v[0-9]*'` against the source tree the script was invoked from (i.e. `$(Build.SourcesDirectory)`; please.sh's `cd "$(dirname "$0")"` is inside a `$()` subshell, so the main script's cwd is the caller's). If a v[0-9]* tag points at HEAD, that tag's name becomes `$tag`. 2. Otherwise it synthesises `$(git describe --match=v* HEAD | sed 's/-.*//').$(date +%Y%m%d%H%M%S)` and creates a lightweight tag at HEAD with that name. 3. The chosen `$tag` is then pushed into the freshly cloned `/usr/src/MINGW-packages/mingw-w64-git/{git,src/git}` worktrees and is what makepkg-mingw actually builds against. The downstream `make_installers_from_mingw_w64_git` step picks up the resulting `mingw-w64-$(toolchain)-*-${tag#v}-*.pkg.tar.*` and names the Inno Setup `Git-${tag#v}-installer.exe` after it. So the only knob that actually changes the package version on the Windows build is the set of `refs/tags/v[0-9]*` pointing at HEAD in the source tree the Bash@3 task runs in. GIT-VERSION-GEN never gets to look at our `version` file because the source tree it would have read it from (the caller's worktree) is not the source tree makepkg-mingw compiles from. Drop the useless `version`-file write and instead, immediately before the `please.sh` invocation (and after the existing `git config --global user.{name,email}` block, so the annotated tag gets a tagger), check whether `refs/tags/v$(git_version)` already exists at HEAD: if it does (the real release case, where the pipeline triggers on a tag push and resolve-version.sh has already verified the tag), do nothing; otherwise (the TO-DROP debug case, where the tag does not exist in the worktree) create it as an annotated tag pointing at HEAD. The "tag exists" branch additionally compares the tag's pointed-at commit to HEAD and fails loudly via `##vso[task.logissue type=error]` if they differ. Silently skipping creation in that case would let please.sh's `for-each-ref --points-at=HEAD` not find the tag (since it does not point at HEAD), fall back to the `describe + timestamp` path this whole block is supposed to prevent, and produce artifacts named after the wrong version with no obvious indication of why. please.sh's `for-each-ref` then finds our annotated tag on the first try, skips the `describe + timestamp` fallback, pushes the tag into the cloned worktrees, and the rest of the pipeline produces artifacts named after the pipeline-resolved `$(git_version)`. Assisted-by: Claude Opus 4.7 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
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
3 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.
This fix is a rebase of gitgitgadget#400.
The CI builds are failing for Mac OS X due to a change in the
location of the perforce cask. The command outputs the following
error:
So let's try to call
brew cask install perforcefirst (which is whatthat error message suggests, in a most round-about way).
The "caskroom" way was added in 672f51c (travis-ci:
fix Perforce install on macOS, 2017-01-22) and the justification
is that the call "brew cask install perforce" can fail due to a checksum
mismatch: the recipe simply downloads the official Perforce distro, and
whenever that is updated, the recipe needs to be updated, too.
CI servers are typically fresh virtual machines, but not always. To
accommodate for that, let's try harder if
brew cask install perforcefails, by specifically pulling the latest
masterof thehomebrew-caskrepository.This will still fail, of course, when
homebrew-caskfalls behindPerforce's release schedule. But once it is updated, we can now simply
re-run the failed jobs and they will pick up that update.
As for updating
homebrew-cask: the beginnings of automating this inhttps://dev.azure.com/gitgitgadget/git/_build?definitionId=11&_a=summary
will be finished once the next Perforce upgrade comes around.