Skip to content

flowey: add explicit no_incremental flag for cargo builds#3054

Open
justus-camp-microsoft wants to merge 1 commit intomicrosoft:mainfrom
justus-camp-microsoft:no_incremental
Open

flowey: add explicit no_incremental flag for cargo builds#3054
justus-camp-microsoft wants to merge 1 commit intomicrosoft:mainfrom
justus-camp-microsoft:no_incremental

Conversation

@justus-camp-microsoft
Copy link
Contributor

Flowey needs the ability to set if the build is incremental or not so that the build-reproducible pipeline can set it and not have machine-dependent paths as part of its target directory outputs. This change makes that configuration explicit rather than just plumbing in the environment variable based on CI or not.

This change is part of a few remaining changes needed to get OpenHCL building reproducibly across machines.

@justus-camp-microsoft justus-camp-microsoft requested a review from a team as a code owner March 18, 2026 21:43
Copilot AI review requested due to automatic review settings March 18, 2026 21:43
Comment on lines -272 to -278
} else {
// if build locally, use per-package target dirs
// to avoid rebuilding
// TODO: remove this once cargo's caching improves
cmd = cmd
.arg("--target-dir")
.arg(in_folder.join("target").join(&crate_name));
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if this should be removed - has cargo's caching gotten better? How would we even validate that?

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds an explicit no_incremental configuration knob to Flowey’s common cargo-flag plumbing so pipelines (notably the local build-reproducible workflow) can opt out of incremental compilation for more reproducible outputs.

Changes:

  • Introduce no_incremental into shared pipeline/job params and propagate it into cfg_cargo_common_flags.
  • Apply no_incremental in run_cargo_build by setting CARGO_INCREMENTAL=0 when requested.
  • Expose a --no-incremental CLI flag for local pipeline runs and wire it through affected pipelines.

Reviewed changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 3 comments.

Show a summary per file
File Description
flowey/flowey_lib_hvlite/src/_jobs/cfg_common.rs Adds no_incremental to shared job params and forwards it to common cargo flags.
flowey/flowey_lib_common/src/cfg_cargo_common_flags.rs Extends common cargo flags with no_incremental and adds a setter request.
flowey/flowey_lib_common/src/run_cargo_build.rs Consumes no_incremental and sets CARGO_INCREMENTAL=0 when enabled; removes prior local --target-dir behavior.
flowey/flowey_lib_common/src/run_cargo_clippy.rs Updates flags destructuring to tolerate the new field.
flowey/flowey_lib_common/src/run_cargo_doc.rs Updates flags destructuring to tolerate the new field.
flowey/flowey_hvlite/src/pipelines_shared/cfg_common_params.rs Adds --no-incremental to local CLI args and sets no_incremental=true for cloud backends.
flowey/flowey_hvlite/src/pipelines/build_reproducible.rs Forces local reproducible builds to use --locked and --no-incremental.
flowey/flowey_hvlite/src/pipelines/vmm_tests.rs Plumbs no_incremental into common params (set to false).
flowey/flowey_hvlite/src/pipelines/restore_packages.rs Plumbs no_incremental into common params (set to false).
flowey/flowey_hvlite/src/pipelines/custom_vmfirmwareigvm_dll.rs Plumbs no_incremental into common params (set to false).
flowey/flowey_hvlite/src/pipelines/build_igvm.rs Plumbs no_incremental into common params (set to false).

Comment on lines +84 to +86
let crate::cfg_cargo_common_flags::Flags {
locked, verbose, ..
} = flags;
Comment on lines +192 to +194
let crate::cfg_cargo_common_flags::Flags {
locked, verbose, ..
} = flags;
Comment on lines 270 to 274
rt.sh.change_dir(cargo_work_dir);
let mut cmd = flowey::shell_cmd!(rt, "{argv0} {params...}");
if !matches!(rt.backend(), FlowBackend::Local) {
// if running in CI, no need to waste time with incremental
// build artifacts
if no_incremental {
with_env.insert("CARGO_INCREMENTAL".to_owned(), "0".to_owned());
} else {
// if build locally, use per-package target dirs
// to avoid rebuilding
// TODO: remove this once cargo's caching improves
cmd = cmd
.arg("--target-dir")
.arg(in_folder.join("target").join(&crate_name));
}
@justus-camp-microsoft justus-camp-microsoft force-pushed the no_incremental branch 2 times, most recently from a18fad4 to 669ccdc Compare March 18, 2026 22:33
@github-actions
Copy link

rt.sh.change_dir(cargo_work_dir);
let mut cmd = flowey::shell_cmd!(rt, "{argv0} {params...}");
if !matches!(rt.backend(), FlowBackend::Local) {
// if running in CI, no need to waste time with incremental
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we losing this CI optimization?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No the behavior is the same, just more explicitly passed in with the no_incremental flag

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only places using this optimization are CI runs and now the Nix build. This technically could have been another backend check but I think it's better to pass it in explicitly and then have higher level nodes orchestrate whether or not it should set it or not.


let mut env = HashMap::new();
if no_incremental {
env.insert("CARGO_INCREMENTAL".to_owned(), "0".to_owned());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where is this used? Also does incremental matter for doc/clippy runs?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It shouldn't matter for docs, I think I did this to make it more consistent but I think a better thing to do here is just destructure it and ignore it. I'll push a change that does that. For clippy I think this was already plumbed so I'm keeping the same behavior there.

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds an explicit no_incremental configuration knob to Flowey’s shared cargo-flag plumbing so pipelines (notably reproducible builds) can deterministically control whether incremental compilation is disabled, instead of relying on backend/CI heuristics.

Changes:

  • Introduce no_incremental in the common cfg (cfg_common) and cargo flags node (cfg_cargo_common_flags) and thread it through hvlite pipeline parameter wiring.
  • Update cargo build and cargo clippy Flowey nodes to set CARGO_INCREMENTAL=0 only when no_incremental is requested.
  • Add a --no-incremental CLI flag for local runs and default no_incremental: true for cloud params.

Reviewed changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 2 comments.

Show a summary per file
File Description
flowey/flowey_lib_hvlite/src/_jobs/cfg_common.rs Plumbs no_incremental from common job params into the shared cargo-flags node.
flowey/flowey_lib_common/src/cfg_cargo_common_flags.rs Extends the shared Flags struct and request API with no_incremental.
flowey/flowey_lib_common/src/run_cargo_build.rs Uses Flags.no_incremental to conditionally set CARGO_INCREMENTAL=0 during builds.
flowey/flowey_lib_common/src/run_cargo_clippy.rs Uses Flags.no_incremental to conditionally set CARGO_INCREMENTAL=0 during clippy.
flowey/flowey_lib_common/src/run_cargo_doc.rs Adjusts destructuring for the new flag (currently ignored).
flowey/flowey_hvlite/src/pipelines_shared/cfg_common_params.rs Adds --no-incremental to local CLI args; sets no_incremental: true for cloud defaults.
flowey/flowey_hvlite/src/pipelines/build_reproducible.rs Sets locked + no_incremental explicitly for the local reproducible build pipeline.
flowey/flowey_hvlite/src/pipelines/build_igvm.rs Threads no_incremental into cfg_common params for this pipeline path.
flowey/flowey_hvlite/src/pipelines/vmm_tests.rs Adds no_incremental field when constructing cfg_common params.
flowey/flowey_hvlite/src/pipelines/restore_packages.rs Adds no_incremental field when constructing cfg_common params.
flowey/flowey_hvlite/src/pipelines/custom_vmfirmwareigvm_dll.rs Adds no_incremental field when constructing cfg_common params.

Comment on lines 14 to 26
pub struct Flags {
pub locked: bool,
pub verbose: bool,
pub no_incremental: bool,
}

flowey_request! {
pub enum Request {
SetLocked(bool),
SetVerbose(ReadVar<bool>),
SetNoIncremental(bool),
GetFlags(WriteVar<Flags>),
}
Copy link

Copilot AI Mar 19, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Flags now carries no_incremental, and run_cargo_build/run_cargo_clippy respect it, but other cargo entry points still hardcode CARGO_INCREMENTAL=0 based on backend (e.g., nextest command generation/archive). That makes the behavior inconsistent and undermines making incremental control explicit; consider switching those call sites to use Flags.no_incremental and removing the backend-based override.

Copilot uses AI. Check for mistakes.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This may actually be a good comment, let me grep to make sure this shouldn't be plumbed through in other places that I missed.

@github-actions
Copy link

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

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

Successfully merging this pull request may close these issues.

3 participants