abderrahim commented on PR #2005: URL: https://github.com/apache/buildstream/pull/2005#issuecomment-2888822388
> I think we already have a similar test in `tests/integration/cachedfail.py::test_push_cached_fail()`, perhaps this requires constructing a dependency chain which fails the existing test but passes with this change applied ? I think there is a misunderstanding here. What this test does (and what makes me confident that my changes don't break anything) is test for correctness "buildstream pushes the artifacts it has built before quitting". While my change is about interactivity "buildstream quits ASAP when asked to". I don't think I can reliably test for the interactivity part as buildstream isn't deterministic (or at least it isn't guaranteed to be deterministic) in the order in which it schedules ready jobs. How I would test this manually is to have two build jobs that would run in parallel, set --builders to 1, then interrupt the build and request quit during the build of the first element that gets scheduled. Talking this through, I think we might be able to do the same thing with failed builds: have two elements that fail, launch the build with `--on-error quit`, and assert that only one of two elements gets built and pushed. I'll give it a go. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
