release: make apt non-interactive in the build container - #312
Merged
Merged
Conversation
The 0.5.1 pipeline failed on both architectures before building anything: dist installs the apt dependencies from dist-workspace.toml with a plain `apt-get install`, no `-y`, and inside the buildpack-deps container apt asked "Do you want to continue?" and answered itself "Abort". The step is generated by dist and takes no flags (axodotdev/ cargo-dist#2353); on GitHub's own runners it works only because their apt is configured to assume yes, which the container's is not. The same workflow built 0.5.0 eight days earlier on an earlier build of the same image. dist's github-build-setup inserts steps into every build job before it installs dist and its dependencies. The one added here configures apt the way the runners do and sets DEBIAN_FRONTEND, in the container, so dist's own line succeeds whatever the image does. Verified by running the step and then dist's exact apt line, stdin closed, in buildpack-deps:22.04: libpam0g-dev installs, exit 0. release.yml regenerated with dist 0.33.0; the diff is the inserted step.
pierre-warnier
added a commit
that referenced
this pull request
Sep 15, 2026
…ectory (#313) GitHub reads every YAML file directly under .github/workflows as a workflow. The build-setup file added for dist is a bare list of steps, not a workflow, and GitHub reported it as a failing one on every push to main since #312. dist resolves github-build-setup relative to .github/workflows, so the file moves one directory down, where GitHub does not look. release.yml regenerated: identical, the steps it inlines are the same.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The 0.5.1 release pipeline failed on both architectures before building anything. dist installs the apt dependencies from
dist-workspace.tomlwith a plainapt-get install, no-y, and inside thebuildpack-depscontainer apt asked Do you want to continue? and answered itself Abort. That step is generated by dist and takes no flags (axodotdev/cargo-dist#2353); on GitHub's own runners it works only because their apt is configured to assume yes, which the container's is not. The same workflow built 0.5.0 eight days earlier on an earlier build of the same image.Fix. dist's
github-build-setupinserts steps into every build job before it installs dist and its dependencies. The one added here writesAPT::Get::Assume-Yes "true"into the container's apt configuration and setsDEBIAN_FRONTEND=noninteractive, so dist's own line succeeds whatever the image does.release.ymlregenerated with dist 0.33.0; the diff is the inserted step, landing before Install dist and Install dependencies.Verified by running the step and then dist's exact apt line, stdin closed, in
buildpack-deps:22.04:libpam0g-devinstalls, exit 0,pam_appl.hpresent.After merge the
0.5.1tag is moved to the new main commit and the pipeline rerun; no release object or asset was ever published for the first attempt, so nothing downstream has seen the old tag.