Enrico Tassi (Jul 29 2020 at 10:30): Enrico Tassi (Jul 29 2020 at 10:30):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)
Théo Zimmermann (Jul 29 2020 at 10:33):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.
Théo Zimmermann (Jul 29 2020 at 10:34):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.
Enrico Tassi (Jul 29 2020 at 11:09):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?
Enrico Tassi (Jul 29 2020 at 11:12):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.
Théo Zimmermann (Jul 29 2020 at 12:26):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