The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage

For detailed information about the code coverage, see the test coverage report.

Reviews

See the guideline for information on the review process.

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #29091 ([28.x] build: Bump g++ minimum supported version to 11 by maflcko)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

CI failure can be ignored

Mostly just asking for curiousity, since I guess I can rebase, but in some of my PR's I see:

./ci/test/00_setup_env.sh: line 33: ./ci/test/00_setup_env_native_qt5.sh: No such file or directory

https://cirrus-ci.com/task/5895775641665536
https://cirrus-ci.com/task/5238795365253120

And I'm confused about why this happens. Which cirrus is running, is it mixing and matching the cirrus configuration and scripts from different branches?

Yes, Cirrus is merging the code changes with the target branch, but not the config changes with the target branch. Thus, the config will have a reference to a file name, which no longer exists in the code.

Ideally this is fixed upstream (there is an issue already open).

However, in the meantime, I think the error can be ignored.

If you want, and there is no review (or reviewers are happy to re-ACK), you can rebase your pull requests on current master.

Would it maybe make sense to have a wiki page with a reverse chronological list of known CI failures? I think it would be useful to have a simple place to check if there is a known issue when a CI job is failing, but I'm not sure if it would create a maintenance burden.

Would it maybe make sense to have a wiki page with a reverse chronological list of known CI failures?

I think it would be easier to have each as an issue, which can be reverse chronologically sorted, or in any other way. There is a Tests label, but a new label can be added, if a dedicated "category" is needed. See, https://github.com/bitcoin/bitcoin/issues?q=is%3Aissue+is%3Aopen+label%3ATests

Using the issue tracker would also make it easy to search?

a new label can be added, if a dedicated "category" is needed

I think this would be great. Ideally there would just be some link you could go to quickly see recent known CI failures and what the expected error messages look like.

This could avoid the need to debug and search for fragments of error messages when CI tasks are failing. I think a filtered issue list would work just as well as a wiki page (but I might experiment with creating a wiki page anyway since I'm about to go through my own PRs and take some notes on what's failing).

a new label can be added, if a dedicated "category" is needed

I think this would be great. Ideally there would just be some link you could go to quickly see recent known CI failures and what the expected error messages look like.

Ok, I've recycled the "CI failed" label for this. See https://github.com/bitcoin/bitcoin/issues?q=is%3Aissue+is%3Aopen+label%3A%22CI+failed%22

There are 13 issues right now. (14 if someone creates an issue for the one mentioned in this thread)

If the issue is additionally labelled:

• "Test", then the presumed bug is in the test code (or the location is unknown)
• "Upstream", then the presumed bug is upstream
• Otherwise, the bug is in the mentioned component, for example "Wallet"