Conversation
15240d1 to
e92bdbf
Compare
4979aae to
5d88b3d
Compare
2ae8318 to
fb747c0
Compare
|
Running as |
|
See also bitcoin#29804 (comment) |
|
Sounds like it, but it seems better if this test is skipped if it's missing a permission. The CI machine is still doing enough other useful stuff. |
|
Not sure, as that could mean cirrus is accidentally not testing tracepoints. Recall that the tracepoints are only explicitly enabled on cirrus ( Line 187 in 5825cd8 I'd say to just move the task to GHA and leave it as-is for now. |
That could work too. |
@m3dwards is working on this |
Still a WIP but here is draft PR: bitcoin#30193 |
edit: Oh nvm, you mention that they don't catch it. I misread. The current failure logged to stderr seems to be: |
8d228bb to
3c998b0
Compare
|
bitcoin#30193 landed. Currently trying if Update: giving up on |
ea8303c to
d8229d5
Compare
e66f4e9 to
2981904
Compare
The ci "test-each-commit" job fetches the PR branch being tested with a depth of (# of commits in PR + 2), and then tries to run tests on commits after the most recent merge commit. When a PR is opened against a bitcoin core branch, a merge commit is always guaranteed to exist within the fetch depth, because bitcoin core branches always point at merge commits. However, in fork repositories, pull requests can be opened based on other branches that don't contain recent merge commits, and this will currently cause git rev-list to fail with fatal: bad revision '^^@'. Work around this problem by not requiring a recent merge commit, and just testing on all fetched commits if a merge commit can't be found. Co-authored-by: Ryan Ofsky <[email protected]>
This tests CI for a pull request on a fork against a branch that's not master.
Demo for bitcoin#29274