Cirrus CI will be capping the free compute soon. For now, switch more tasks to persistent worker, as recommended by Cirrus CI.
(See slightly related discussion in #28098)
Also, add more docs.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
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.
No conflicts as of last run.
macOS task has not been started:
UPD: Scheduled in 14 minutes:
UPD: Scheduled in 14 minutes:
When there are pushes to many pull requests at the same time, scheduling may take a few minutes. This is similar to the Cirrus CI hosted open source compute cluster.
ACK fa960fefb589ac97de206f46d7b5c565fc70e3db. I have reviewed the code and it looks OK.
However, I’m a bit reluctant about running macOS-cross job on a persistent worker. I’d prefer run it on GitHub Actions due to the ability to create downloadable artifacts that is used in the QML repo to make designers’ life a bit easier.
I understand, that there is no open PR with such a suggestion for now. But there is an ongoing Linux jobs related discussion in https://github.com/bitcoin-core/secp256k1/pull/1396.
It would be nice if we postpone moving macOS-cross job for a week or two.
It would be nice if we postpone moving macOS-cross job for a week or two.
Done for now. Should be trivial to re-ACK.
re-ACK fa1d8955f69d3934f975f42eb04b5a3fc0d8aa35.
Thank you.
I’d prefer run it on GitHub Actions due to the ability to create downloadable artifacts that is used in the QML repo to make designers’ life a bit easier.
Why can’t this just be done in the QML repo if it’s required there?
128+ persistent_worker:
129+ labels:
130+ type: medium
131 env:
132- << : *CIRRUS_EPHEMERAL_WORKER_TEMPLATE_ENV
133+ FILE_ENV: "./ci/test/00_setup_env_native_tidy.sh"
PERSISTENT_WORKER_TEMPLATE_ENV
?
The reason is that the ENV only sets one env var, which can (and is) also be done directly in the screen command.
RESTART_CI_DOCKER_BEFORE_RUN=1 screen cirrus ...
ACK fa1d8955f69d3934f975f42eb04b5a3fc0d8aa35
Lots of great comments, code change looks good to me and obviously works on ci. I also ran the task locally (although on macOS I had to enter the container and manually install clang with arm support). One question below and also I’m wondering if the output of “include-what-you-use” is used at all? It makes a lot of suggestions but none of that counts as errors?
0-----BEGIN PGP SIGNED MESSAGE-----
1Hash: SHA256
2
3ACK fa1d8955f69d3934f975f42eb04b5a3fc0d8aa35
4-----BEGIN PGP SIGNATURE-----
5
6iQIzBAEBCAAdFiEE5hdzzW4BBA4vG9eM5+KYS2KJyToFAmTT4bgACgkQ5+KYS2KJ
7yTqpug//S8FFIisKLeNiyUR8DjdLK+twfLOvkRu8iVwBsqgTXFQXxWY6xzbDkqTB
8xGpyIGwpJWrREnu9ec2Ru4R8+PPcLwGmKiSET12XfUHWvinrZe0O0nUl1QlckV/h
9shmsJkUzF9Zw839mZXL7UevQCg2QfMXYw+iMYgc0dGXL0qncsWAhphfr6LDCaf+h
10zNEwhx/KfiPszQPlpeb3lJvV4joE4vGJEvUZ2FAt5vRB89b+68tjL4D3l+yKFhiD
11bVT9k7D+nAAmm2suuXM6CSyQBZPEEknhrgK3OfLzDS/RZdrBoDSkrae4KsM9nENs
121TJ0K/x9tZCjQlmTKjEEdOgxv1kCmcQkSwqq57k5q5BjbyfVCAxxYhN7LB0kUdnr
13Ynjs/wzAVYb+kPsWvBi0gbEsl4LuFEGSMsSFTsowtoDlA49TNjTTQwzJMbky9nPh
146A5LBUAZRPlD6rDorEUoxL85Amj/DiL52xsHKF9qnc+yI0n26/xv8gm8WTD7tKc0
15jI2GYVSCD23VBO0wYvan8cxbBDLAjF13eEVtFT4r31RBTxoyWiG0Ty+qd3qMhvKE
16JspOA2sAscWFIjlFVH0AOyvMDU4o1rU7XLHCvFGc9Gj9imWxIpHEOTy0A8q78oSn
17tW4czoaWWXmC3tHphs2/qA90txKM8lUuqi8sl+aqhUqSo8lv1Eg=
18=If5B
19-----END PGP SIGNATURE-----
pinheadmz’s public key is on keybase
I also ran the task locally (although on macOS I had to enter the container and manually install clang with arm support).
Yeah, that’s unrelated, because I only modify the cirrus yml, not the CI task config. Maybe create a separate issue, though I won’t be able to help, since I don’t have or use macOS.
One question below and also I’m wondering if the output of “include-what-you-use” is used at all? It makes a lot of suggestions but none of that counts as errors?
Yeah, that is on purpose and unchanged in this pull. Currently iwyu still has bugs (false negatives and false positives) and there are also trillion true positives and the true negatives sometimes lead to compile errors down the line in other modules.
I think for now it is best to check the iwyu output during review for newly added code or when a module is modified and touched for other reasons.
One question below and also I’m wondering if the output of “include-what-you-use” is used at all? It makes a lot of suggestions but none of that counts as errors?
Yeah, that is on purpose and unchanged in this pull. Currently iwyu still has bugs (false negatives and false positives) and there are also trillion true positives and the true negatives sometimes lead to compile errors down the line in other modules.
I think for now it is best to check the iwyu output during review for newly added code or when a module is modified and touched for other reasons.
Related:
* PERSISTENT_WORKER_TEMPLATE_ENV is not needed at all, because
RESTART_CI_DOCKER_BEFORE_RUN is already set on the persistent worker.
* PERSISTENT_WORKER_TEMPLATE can be replaced by pinning the
previous_releases task to a type of worker. This should make the CI
performance more consistent.