builds.sr.ht CI (freebsd, openbsd) doesn't merge PR's against devel, unlike azure, github, causing issues #17097
Description
this is the root cause for #17093, and probably other mysteries in the past related to "some PR works except under openbsd/freebsd, and problem mysteriously disappears after rebase/merge".
typical CI
in azure pipelines, github actions, and probably most CI's, PR's are merged against repo HEAD on every PR push (or upon events such as closing/reopening). This is an important feature, so that CI reflects latest state of a repo to prevent bad merge (among other things, it catches merge conflicts).
builds.sr.ht CI
in builds.sr.ht CI (freebsd, openbsd), I just discovered (after investigating #17093 and the mysterious CI failures affecting only openbsd/freebsd in #17066), that this isn't the case: PR's aren't merged, and CI just checks out the repo at the commit that was pushed.
I verified this by printing git rev-parse HEAD, and comparing it for builds.sr.ht CI (freebsd, openbsd) vs the other CI (azure, github).
what this means
- JS bool set invalid output with BSD #17093 can be closed, because the problem was fixed in devel even though this wasn't apparent in Add setutils.complement, setutils.fullSet #17066 until it gets rebased)
- if an issue seems to affect only openbsd,freebsd, this could be the reason
- PR's should regularly be rebased (or 2nd best: merged) against latest devel, especially for old PR's, otherwise CI may fail only after the PR was merged
can this be fixed in builds.sr.ht?
IMO this should be fixed in builds.sr.ht (via their issue tracker see https://todo.sr.ht/~sircmpwn/builds.sr.ht); unfortunately, based on this message in another issue I had (builds.sr.ht doesn't work with forks), I'm not sure that it's something that's aligned with their goals:
https://todo.sr.ht/~sircmpwn/builds.sr.ht/279#event-32377
SourceHut does not generally encourage the use of GitHub-style "forks", seeing them as an anti-feature which is designed more to encourage you to incorporate GitHub's centralization more deeply into your workflow than it is designed to speed up or simplify your workflow. We use a much more ad-hoc approach.
EDIT: I just asked in https://lists.sr.ht/~sircmpwn/sr.ht-discuss/%3CCANri%2BEyJDJmonKyDsiQvTh-M5x_bTiEvnD-dOLHutnq_fefYpg%40mail.gmail.com%3E
notes
indeed, azure for eg does as follows:
https://dev.azure.com/nim-lang/Nim/_build/results?buildId=13310&view=logs&j=30931762-47c4-53b3-6a83-316eb5a6b9d7&t=aae324dd-1cd4-58f6-fff9-f86a0050b537
shows:
git checkout --progress --force refs/remotes/origin/cfa4d80f5e8e07aee44d5266c23572cabb8ab0a2
HEAD is now at cfa4d80f Merge 8c19df7974d1ad881609d3f8fcea3d99ff73d2ec into 148e5ba2a5e51f19c51e2c11150e6986c04990ba
Finishing: Checkout nim-lang/Nim@refs/pull/17094/merge to s
whereas in builds.sr.ht (freebsd, openbsd), the CI runs at whatever commit was last pushed, eg:
Cloning into 'Nim'...
+ cd Nim
+ git checkout -q b180248725d224e3541ded60f08161005029b1f4
+ cd Nim
+ git submodule update --init