Repository navigation
Deploy immutable images from selected build Machines - #842
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d5af268096
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| Some("x86_64" | "amd64") => service.built.platform == "linux/amd64", | ||
| Some("aarch64" | "arm64") => matches!(service.built.platform.as_str(), "linux/arm64" | "linux/arm64/v8"), | ||
| _ => false, |
There was a problem hiding this comment.
When a destination daemon reports an architecture other than x86-64 or ARM64, this branch unconditionally rejects the deployment even if the completed image matches it. The build protocol already accepts platforms such as linux/386, linux/arm/v7, and linux/ppc64le, so deployments to corresponding x86, arm, or powerpc64 Machines are refused before transfer; map every supported runtime architecture to its OCI platform instead of treating the remainder as incompatible.
Useful? React with 👍 / 👎.
| let retained = format!( | ||
| "{}/{}:ployz-build-{}", | ||
| reference.registry(), | ||
| reference.repository(), | ||
| uuid::Uuid::new_v4() |
There was a problem hiding this comment.
Every Output::Load build, including an ordinary ployz build, creates a fresh :ployz-build-<uuid> tag, but no completion or cleanup path removes it. Repeated builds therefore leave every historical image permanently tagged, preventing normal dangling-image pruning and steadily consuming Docker storage; retain these tags only for the bounded build/delivery operation and remove them afterward.
Useful? React with 👍 / 👎.
# Conflicts: # crates/ployz-build/src/lib.rs # crates/ployz-build/src/remote.rs # crates/ployz-build/src/upload.rs # crates/ployz/src/compose/build.rs
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e09f5676ba
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| for image in request.image_contexts.values() { | ||
| for target in request.targets { | ||
| let platform = target.platform.as_deref().unwrap_or(&native); | ||
| if !covers(&image.platform, platform) { |
There was a problem hiding this comment.
When a cross-platform consumer intentionally uses a dependency built for another architecture—for example, an ARM64 target with FROM --platform=linux/amd64 base—this unconditional comparison rejects the build during preparation. Named image contexts can legitimately differ from the output platform, including when copying architecture-independent artifacts, so BuildKit should validate how the context is consumed rather than requiring every context to match the target platform.
Useful? React with 👍 / 👎.
# Conflicts: # crates/ployz-build/src/lib.rs # crates/ployz-build/src/upload.rs # crates/ployz/src/compose/remote_build.rs # crates/ployz/src/handlers/build.rs # crates/ployz/tests/build_layer3/remote.rs # crates/ployzd/src/build.rs
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 722930f2a1
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| let inputs = Self::new()?; | ||
| // ponytail: copy the already-filtered capture per remote target. Select | ||
| // per-target source trees if large multi-Service captures become costly. | ||
| for area in ["source", "private"] { |
There was a problem hiding this comment.
When execute_on_machines assigns dependent builds to different Machines, this loop copies the complete shared source and private trees into every per-Service upload. Filtering the Compose document later does not remove unrelated Services' source trees, secret files, or SSH keys, so each selected Machine receives credentials and code belonging only to builds assigned elsewhere; construct each capture from only the inputs referenced by that target.
Useful? React with 👍 / 👎.
| .await?; | ||
| let descriptor: serde_json::Value = serde_json::from_str(&descriptor)?; | ||
| if descriptor.get("digest").and_then(serde_json::Value::as_str) != Some(digest) { | ||
| return Err(Error::PeerPull(format!( |
There was a problem hiding this comment.
For digest-based delivery, if the pull and tag succeed but the newly added inspect, JSON decoding, or descriptor comparison fails, these early exits bypass the removal at line 61. The failed destination therefore retains both the unique 127.0.0.1:<port>/... reference and the digest-retention tag, allowing failed deliveries of successive builds to accumulate image content; run cleanup on every post-pull exit while preserving the verification error.
Useful? React with 👍 / 👎.
# Conflicts: # crates/ployz-build/src/lib.rs # crates/ployz/src/compose/build.rs # crates/ployz/src/compose/remote_build.rs # crates/ployz/src/deploy/apply.rs # crates/ployz/src/deploy/pipeline.rs # crates/ployz/src/handlers/deploy.rs # crates/ployz/src/handlers/deploy_tests.rs # crates/ployz/src/image.rs
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6e32e1c12d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| let tag = self | ||
| .tags | ||
| .first() |
There was a problem hiding this comment.
When a Compose service declares explicit build.tags, capture preserves those tags before appending service.image, so the first metadata tag can name an auxiliary repository. Using that first tag here causes bind_builds and image delivery to use auxiliary-repo@sha256:... rather than the repository declared by the Service; for local deploys, an auxiliary repository containing a registry port can additionally trigger RegistryPortReference even when service.image itself is supported. Construct the digest reference from BuiltService.image instead of arbitrary tag ordering.
Useful? React with 👍 / 👎.
* Deploy immutable images from selected build Machines * Release temporary build tags and validate destination architectures * Let BuildKit validate cross-platform named image contexts --------- Co-authored-by: Codex <codex@codex-vm.tailcb9c5.ts.net>
ployz deploy --remote=<Machine>builds on the selected Machine and deploys its completed images without inspecting local Docker or publishing to a registry. Runtime Services bind to manifest digests, so reusing a requested tag cannot substitute another build’s content.Builds run in dependency order, including
service:contexts served from the dependency’s actual build Machine. All required builds finish before application changes. Destination platform checks cover architecture aliases and known ARM generations; direct transfer retains per-Machine successes, failures, and omissions.Temporary image tags stay alive through dependent builds and delivery, then are released with the completed image results. Captured source and credential files retain their original cleanup lifetime.
Validation:
ployz-buildlibrary tests, including reserved-tag validation; destination architecture/ARM compatibility checks.ployzlibrary tests and 25 build integration tests passed. All 9 daemon Build tests passed, including remote image retention and release. Local clone/drop and remote drop regressions were rerun after the final ownership adjustment.remote_build_delivers_dependency_content_and_deploys_without_a_registryon two real Docker Machines, including cross-Machine dependency builds. The added temporary-tag cleanup assertions have not been rerun on real Machines.After merging the queue/admission changes from main, validation passed again: 31 shared Build unit tests, 14 daemon Build tests, 10 remote client tests, 2 remote CLI tests, and workspace Clippy. The completed-image regression also verifies that retained images release admission for the next Build and are cleaned up on daemon shutdown.
The subsequent main merge preserves multi-platform Railpack output and caller-owned cancellation. Latest checks: 31 shared Build unit tests, 364 client unit tests, 30 Build integration tests, 14 daemon Build tests, 2 remote CLI tests, and workspace Clippy all passed. The remote deploy regression covers combined AMD64/ARM64 image evidence.
Named image contexts may contain a different architecture from the output target; BuildKit validates their consumption. Rung 1 regression
cross_platform_image_context_reaches_buildkitfailed before removing the unconditional platform comparison and passed afterward; all 32 shared Build unit tests pass.Closes #803.