Even if Coq does not build (even the base job) coqbot still reports that the allowed_failure jobs did fail, and this pollutes the discussion thread. I know these messages will eventually be posted in the CI box, bot for now it could make sense to post a message only if the base job did succeed.
Alternatively we can make these jobs artificially depend on the base job (which may not be a bad idea in general, since if base fails so many other jobs are doomed to fail, not only the ones that are allowed to fail)
We could check for the already reported status and if "base: build" is among them, or if there are too many failing statuses, we would not post a comment. However, I also like the idea of fixing this at the pipeline level.
I am thinking of something like: if the base build fails, cancel all the other running jobs. This would avoid delaying the rest of the jobs but still prevent the spurious notifications.
This works if the base job is picked up first and is faster than the others. It makes sense. But would we lose time overall?
I mean: running base before anything else does not change much in terms of dependency "depth", since the jobs you would artificially put after it don't have long dependencies on them.
Sure, it depends on what job we are talking about. In the case of async, it makes sense to postpone it after we've checked that the build went through. For some other jobs like the Windows job, it makes sense to start it early and to cancel it if we know it's gonna fail anyway.
Last updated: Sep 28 2023 at 11:01 UTC