Update perforce from 2021.1,2126753 to 21.1,2156517#108819
Update perforce from 2021.1,2126753 to 21.1,2156517#108819miccal merged 1 commit intoHomebrew:masterfrom
Conversation
dscho
force-pushed
the
perforce
branch
3 times, most recently
from
890dfe5 to
6707962
Compare
|
Finally! The build passed! |
The PR to update to this version is here: Homebrew/homebrew-cask#108819 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Casks/perforce.rb
Outdated
There was a problem hiding this comment.
This seems more likely that they didn't publish this release properly yet, or we're looking at the wrong source for the releases.
There was a problem hiding this comment.
I thought so, too, but the CI builds are failing for multiple days now, and there are quite a few of those builds: https://github.com/git/git/actions/workflows/main.yml
(Yes, Perforce has this tradition of releasing on a Friday night...)
There was a problem hiding this comment.
Oh, and for the record, I had to add a workaround for a similar issue in the past. IIRC I disabled the automated builds for a couple of weeks in the hopes that they would update their website to reflect the actual version, but even a couple of weeks had not been enough.
Therefore, in the interest of unbreaking each and every CI build of the Git project, I would like to respectfully request to just go with the pragmatic workaround. If you truly care deeply, I will monitor the release notes manually and open a PR, should the release notes ever been updated to include the current version.
Deal?
There was a problem hiding this comment.
Can you shoot them an email to clarify the state of this latest release and just keep this PR to the SHA/version change? I'd rather not mess with the livecheck if we can avoid it.
There was a problem hiding this comment.
I tried to contact Perforce's support years ago, but never heard back from them because you know, I am not a paying customer. All I need it for is to verify Git's Perforce support. I have no illusions about the prospect of getting anybody on the line this time around, either.
Me, too, I would love to avoid the livecheck issues, but unfortunately, I do not see any pragmatic way out of this without hardcoding known-bad information and its known-good replacement.
The alternative is, of course, to leave the Git project with completely broken CI runs. Not something I was working toward.
There was a problem hiding this comment.
My alternative would be to leave the livecheck broken and merge just the version update.
There was a problem hiding this comment.
But then it would look as if my PR was crafted carelessly.
There was a problem hiding this comment.
I think this discussion proves otherwise.
There was a problem hiding this comment.
As you wish. I force-pushed, dropping the livecheck workaround (and explaining in the remaining commit message why we accept the failing livecheck).
Please note that this fails the livecheck because Perforce's release notes were not updated when the binaries were uploaded (overwriting the previous version's binaries, of course). During the review of Homebrew#108819 it was determined that it is worth having a failing livecheck more than it is worth having an ugly workaround (for future record, the ugly workaround is here: Homebrew@670796228). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
For posterity: As expected, the audit failed and consequently the conclusion, too: This was determined to be okay because the livecheck depends on Perforce's release notes to be up to date, which they are not. |
3 participants
Verified:
Not verified (because I only want to fix this for git/git, where all CI builds are failing because of this:
brew audit --cask <cask>is error-free.brew style --fix <cask>reports no offenses.