lix-project/lix

Fork 48

A single build failure should (optionally?) not kill other running builds #878

New issue

Open

opened 2025-06-25 18:04:54 +00:00 by k900 · 7 comments

k900 commented

2025-06-25 18:04:54 +00:00

Member

We've all been there. You're building your system config, your Chromium build that took five hours is almost done, and oops, farts.conf failed to validate, and you forgot to --keep-going, and now the entire build tree is dead and so are five hours of your life. We should have a mode that's kind of like --keep-going, except it stops scheduling new builds, but waits for existing ones to complete before failing, and we should have that be the default.

We've all been there. You're building your system config, your Chromium build that took five hours is almost done, and oops, `farts.conf` failed to validate, and you forgot to `--keep-going`, and now the entire build tree is dead and so are five hours of your life. We should have a mode that's kind of like `--keep-going`, except it stops scheduling _new_ builds, but waits for existing ones to complete before failing, and we should have that be the default.

👍 4

k900 added the

Area/cli

labels

2025-06-25 18:04:54 +00:00

samueldr commented

2025-06-25 18:10:27 +00:00

Member

Suggestions for name:

--finish-builds
--complete-builds
~~--complete-builds-on-failure~~ is probably too long

Another option:

Enhancing --keep-going with =$MODE (only = form accepted) where --keep-going being left unqualified resolves to the mode name equivalent to the current behaviour (i.e. exhaust every builds). So e.g. --keep-going=only-complete-builds or some more concise mode name.

Suggestions for name: - `--finish-builds` - `--complete-builds` - ~~`--complete-builds-on-failure`~~ is probably too long Another option: Enhancing `--keep-going` with `=$MODE` (only `=` form accepted) where `--keep-going` being left unqualified resolves to the mode name equivalent to the current behaviour (i.e. exhaust every builds). So e.g. `--keep-going=only-complete-builds` or some more concise mode name.

mweinelt commented

2025-06-25 18:53:03 +00:00

Member

If we turn this around then the flag could be --fail-fast, inspired by various CI systems.

If we turn this around then the flag could be `--fail-fast`, inspired by various CI systems.

k900 commented

2025-06-25 18:54:57 +00:00

Author

Member

So --fail-fast and --fail-faster? xp

So `--fail-fast` and `--fail-faster`? xp

🫠 1

samueldr commented

2025-06-25 18:56:07 +00:00

Member

One issue I'd have is --fail-fast seems like the current strategy. That is, it aborts ASAP all the builds on first failure.

--fail-fast would make sense with a (not that much) breaking change where the default is to finish current builds, and --fail-fast becomes the flag to get the current behaviour.

One issue I'd have is `--fail-fast` seems like the current strategy. That is, it aborts ASAP all the builds on first failure. `--fail-fast` would make sense with a (not that much) breaking change where the *default* is to finish current builds, and `--fail-fast` becomes the flag to get the current behaviour.

k900 commented

2025-06-25 18:58:24 +00:00

Author

Member

My non-joke proposal would be:

default is the new behavior
--fail-fast becomes the old keep-going = false behavior
--keep-going keeps the old keep-going = true behavior

My non-joke proposal would be: - default is the new behavior - `--fail-fast` becomes the old `keep-going = false` behavior - `--keep-going` keeps the old `keep-going = true` behavior

👍 4

samueldr commented

2025-06-25 19:02:28 +00:00

Member

Changing the default also makes sense in a "principle of least astonishment" point of view, that builds that are not yet failed, and could be successful, be tried to be completed. After all, we know that they did not depend on the current failure. So I guess it's likely enough that they will not be affected by whatever change would fix the current failure.