flowey: persist job platform/arch in pipeline static DB#3052
Conversation
There was a problem hiding this comment.
Pull request overview
Persists per-job platform and architecture into Flowey’s generated pipeline static DB JSON so runtime snippet execution can use the job’s resolved environment (including Nix) instead of re-detecting host platform/arch at runtime.
Changes:
- Add
Serialize/Deserializederives toFlowPlatformLinuxDistro,FlowPlatform, andFlowArchso they can be encoded into the pipeline static DB. - Populate
job_platformsandjob_archsmaps when emitting GitHub/ADO pipelines. - Update
ExecSnippetto read platform/arch frompipeline.jsonper job index.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| flowey/flowey_core/src/node.rs | Make platform/arch enums serializable for persistence in the static DB JSON. |
| flowey/flowey_cli/src/pipeline_resolver/github_yaml/mod.rs | Record per-job platform/arch into the pipeline static DB during GH YAML emission. |
| flowey/flowey_cli/src/pipeline_resolver/ado_yaml.rs | Record per-job platform/arch into the pipeline static DB during ADO YAML emission. |
| flowey/flowey_cli/src/cli/exec_snippet.rs | Load per-job platform/arch from pipeline.json and extend the static DB schema. |
| pipeline_static_db | ||
| .job_platforms | ||
| .insert(job_idx.index(), platform); | ||
| pipeline_static_db.job_archs.insert(job_idx.index(), arch); | ||
|
|
| pipeline_static_db | ||
| .job_platforms | ||
| .insert(job_idx.index(), platform); | ||
| pipeline_static_db.job_archs.insert(job_idx.index(), arch); |
3fb1618 to
12e332d
Compare
| serde_json::from_reader(pipeline_static_db)? | ||
| }; | ||
|
|
||
| let flow_platform = *job_platforms |
There was a problem hiding this comment.
I feel like we're using platform and arch in a lot of other places, like in nodes, should they be updated too?
There was a problem hiding this comment.
This is definitely a valid comment and probably worth looking into - in general I'm not a fan (and I don't think Daniel was either) of nodes checking backends because it makes it hard to reason about what the node will do from reading its source code alone.
In general I think it's better to make parameters that change behavior be part of the request and have higher level nodes request them based on the backend (so hoist it up as high as is reasonable) that way nodes are more readable.
12e332d to
3df8cc6
Compare
| @@ -85,6 +82,13 @@ impl ExecSnippet { | |||
| serde_json::from_reader(pipeline_static_db)? | |||
There was a problem hiding this comment.
serde_json::from_reader(pipeline_static_db)? will surface a raw serde error if pipeline.json is missing/older-schema. Consider adding an anyhow::Context here that points to the likely remediation (ensure the job staged the correct pipeline.json for this flowey binary / regenerate in runtime mode).
| serde_json::from_reader(pipeline_static_db)? | |
| serde_json::from_reader(pipeline_static_db).context( | |
| "failed to deserialize pipeline.json; ensure this flowey binary has the correct \ | |
| pipeline.json staged, or regenerate it in runtime mode", | |
| )? |
| .context("invalid job_idx: missing platform")?; | ||
| let flow_arch = *job_archs | ||
| .get(&job_idx) | ||
| .context("invalid job_idx: missing arch")?; |
There was a problem hiding this comment.
The errors "invalid job_idx: missing platform/arch" can also occur when pipeline.json is present but was generated by an older flowey (or otherwise doesn't include these per-job entries). Consider making the message more actionable by including the job_idx value and hinting that the staged pipeline.json may be out of date for this flowey binary.
| .context("invalid job_idx: missing platform")?; | |
| let flow_arch = *job_archs | |
| .get(&job_idx) | |
| .context("invalid job_idx: missing arch")?; | |
| .with_context(|| { | |
| format!( | |
| "invalid job_idx {job_idx}: missing platform (pipeline.json may be out of date for this flowey binary)" | |
| ) | |
| })?; | |
| let flow_arch = *job_archs | |
| .get(&job_idx) | |
| .with_context(|| { | |
| format!( | |
| "invalid job_idx {job_idx}: missing arch (pipeline.json may be out of date for this flowey binary)" | |
| ) | |
| })?; |
| @@ -945,7 +945,7 @@ pub enum FlowPlatformKind { | |||
| } | |||
|
|
|||
| /// The kind platform the flow is being running on, Windows or Unix. | |||
There was a problem hiding this comment.
The doc comment above FlowPlatformLinuxDistro says it's the platform kind (Windows/Unix), but this enum actually represents the Linux distro. Updating the comment would avoid confusion for callers and keep docs aligned with the type's purpose.
| /// The kind platform the flow is being running on, Windows or Unix. | |
| /// The Linux distribution the flow is running on. |
3df8cc6 to
fbb5ed6
Compare
fbb5ed6 to
925be9f
Compare
925be9f to
8e5c6ea
Compare
Right now flowey gets its platform and arch at runtime, but since Nix has been introduced as a flavor of Linux distro that we want to be set at job level, there needs to be a way to set this per-job and have it persist. This change encodes the platform and arch as part of the generated JSON when flowey executes a pipeline and enables us to correctly select the platform if Nix has been set to be used in a job. This is part of a series of changes needed to get to a reproducible build that runs all of our build command and dependencies through Nix.
Right now flowey gets its platform and arch at runtime, but since Nix has been introduced as a flavor of Linux distro that we want to be set at job level, there needs to be a way to set this per-job and have it persist. This change encodes the platform and arch as part of the generated JSON when flowey executes a pipeline and enables us to correctly select the platform if Nix has been set to be used in a job.
This is part of a series of changes needed to get to a reproducible build that runs all of our build command and dependencies through Nix.