Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make the "plan" phase as similar to the "build" phase as possible #1639

Open
4 tasks
duckinator opened this issue Dec 13, 2024 · 0 comments
Open
4 tasks

Make the "plan" phase as similar to the "build" phase as possible #1639

duckinator opened this issue Dec 13, 2024 · 0 comments

Comments

@duckinator
Copy link
Contributor

duckinator commented Dec 13, 2024

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:

  1. Implement a --dry-run flag for dist build.
  2. Make generated workflows use the same matrix for the "plan" phase as for the "build" phase, just with --dry-run.
  3. Implement dist plan in terms of dist build --dry-run
  4. Split out a dist env-test command out of dist build, like was done with dist migrate and dist 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:

  • 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
fn print_tool_status(tool: DistResult<&Tool>) {
    match tool {
        Ok(tool) => println!("✅ located {}", tool.cmd),
        Err(err) => println!("🗙 missing {}", err.tool),
    }
    
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant