You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If --dry-run is passed, anything that would change the state of the system should be explained but not actually run.
2. Make workflows have more consistent "plan" and "build" matrices
There's two ways to approach this:
just generate almost the same exact thing twice
move it to a separate workflow where you can specify additional dist build flags, and use workflow-dispatch twice
Part of the goal of doing this is to fail in the plan phase if tools can't be installed.
3. Implement dist plan in terms of dist build --dry-run
If we have dist build implemented in terms of do_build(cfg: &Config, dry_run: bool, incoherent_tags: bool), then dist build can be implemented as do_build(&config, dry_run, false) and dist plan can be implemented as do_build(&config, dry_run, true).
4. Split out a dist env-test command from dist build, like was done with dist migrate and dist init
Having a separate command that basically goes "can i even theoretically use this environment?" and failing early if the answer is no, would be very useful.
E.g., there's no point going through like 3/4ths of the build process only to fail when finding omnibor, if we can just have something that starts with if needs_omnibor { print_tool_status(dist_graph.tools.omnibor()); }
assuming print_tool_status() is something like this
The ultimate goal of this is to try to catch as many problems that aren't build failures in the plan phase.
Sub-goals to achieve that:
--dry-run
flag fordist build
.--dry-run
.dist plan
in terms ofdist build --dry-run
dist env-test
command out ofdist build
, like was done withdist migrate
anddist init
. (Partially done in Fail early if required tools can't be found. #1640.)1.
dist build --dry-run
If
--dry-run
is passed, anything that would change the state of the system should be explained but not actually run.2. Make workflows have more consistent "plan" and "build" matrices
There's two ways to approach this:
dist build
flags, and use workflow-dispatch twicePart of the goal of doing this is to fail in the plan phase if tools can't be installed.
3. Implement
dist plan
in terms ofdist build --dry-run
If we have
dist build
implemented in terms ofdo_build(cfg: &Config, dry_run: bool, incoherent_tags: bool)
, thendist build
can be implemented asdo_build(&config, dry_run, false)
anddist plan
can be implemented asdo_build(&config, dry_run, true)
.4. Split out a
dist env-test
command fromdist build
, like was done withdist migrate
anddist init
Having a separate command that basically goes "can i even theoretically use this environment?" and failing early if the answer is no, would be very useful.
E.g., there's no point going through like 3/4ths of the build process only to fail when finding omnibor, if we can just have something that starts with
if needs_omnibor { print_tool_status(dist_graph.tools.omnibor()); }
assuming
print_tool_status()
is something like thisThe text was updated successfully, but these errors were encountered: