ci: Run asan ci config on cirrus #19321
Conversation
|
Concept ACK. |
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsReviewers, this pull request conflicts with the following ones:
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. |
| container: | ||
| image: ubuntu:bionic |
There was a problem hiding this comment.
Since this task is one of those that require the greatest amount of time to complete, is it worth to increase the number of the dedicated CPUs, say from 2 to 3 or 4?
| memory: 6G # https://cirrus-ci.org/guide/linux/#linux-containers | ||
| env: | ||
| PACKAGE_MANAGER_INSTALL : "apt-get update && apt-get install -y" | ||
| MAKEJOBS: "-j4" |
There was a problem hiding this comment.
This setting does not corresponds with cpu: 2, no?
There was a problem hiding this comment.
Everything should be identical to what it is on travis (except the timeout)
This is the default value, see
ci/test/00_setup_env.sh:export MAKEJOBS=${MAKEJOBS:--j4}
|
Got unit test fail: https://cirrus-ci.com/task/4876861824040960 |
|
I've observed "Automatic Re-Run" behavior of Cirrus CI. Did not find its description in the docs. |
There was a problem hiding this comment.
Tested on forked repo -- works as expected.
Also tested on forked repo with disabled UBSan suppressions -- errors are catched by UBSan: https://cirrus-ci.com/task/6376713561047040
Also the 03_before_install.sh should be untied from Travis in a followup.
|
automatic re-run should only happen if an error occurs outside our ci script. For example, a network failure to fetch the repo from GitHub or when the preemptible google vm that cirrus is using gets killed. |
fa8e6df ci: Run tsan ci config on cirrus (MarcoFalke) Pull request description: Fixes bitcoin-core/gui#12 Copied description from #19321: Currently it is not possible to use travis in forked repositories due to the 50 minute limit on builds. A fresh build (uncached) of the thread sanitizer config takes more than 50 minutes. One approach to fix this could be to throw away tests until the run time is less than 50 minutes. However, the risk of being blind of failures in the thrown away tests is not worth the gain. Also, to detect them, one has to run the tsan configuration nightly and failures could only be detected post-merge. Another approach would be to ask travis support to raise the limit for a forked repository. This is a tedious and manual one-by-one process, so I'd rather not. Finally, a different ci provider can be used, since the config files are designed to be platform-agnostic. This is what I picked. I kept all settings identical to the travis machine for now. Both providers run in the google cloud, so this should be a "move-only". ACKs for top commit: fanquake: ACK fa8e6df - my understanding is that test coverage remains the same. Just swapping providers to work-around the Travis time-limit in other repos. Tree-SHA512: 26fed248a4f743107160d3b9e5df57fa0be280fd065ae6fece83d254f59d58ccf3e11a245519d158da109c47b053f62ee8756215008541973c65dc28c4efb748
Currently it is not possible to use travis in forked repositories due to the 50 minute limit on builds. A fresh build (uncached) of the address sanitizer config takes more than 50 minutes.
One approach to fix this could be to throw away tests until the run time is less than 50 minutes. However, the risk of being blind of failures in the thrown away tests is not worth the gain. Also, to detect them, one has to run the asan configuration nightly and failures could only be detected post-merge.
Another approach would be to ask travis support to raise the limit for a forked repository. This is a tedious and manual one-by-one process, so I'd rather not.
Finally, a different ci provider can be used, since the config files are designed to be platform-agnostic. This is what I picked.
I kept all settings identical to the travis machine for now. Both providers run in the google cloud, so this should be a "move-only".