Hold insert-ordered-containers below 0.3 in the image too - #344
Merged
Conversation
The image build writes its own cabal.project rather than copying the repository's, so the hold added for the library's 0.3 release never reached it, and allow-newer on the line above let the breaking version in. Building the engine from its sources stopped at API.Types, on the same mismatch between the plain InsOrdHashMap the schema code builds and the compat newtype openapi3 3.2.5 wraps it in from that version on. The published image never hit this: volca-image.yml downloads the released binary and shadows the haskell-builder stage with it, so BuildKit does not build that stage at all. What was broken is the path that compiles: docker-build.sh from source, and the image step of the deployment repository's release gate. Verified by building the haskell-builder stage through to a statically linked binary.
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 image build writes its own
cabal.projectatdocker/Dockerfile:129rather than copying the repository's, so the hold added when
insert-ordered-containers released 0.3 never reached it, and the
allow-newer: trueon the line above let the breaking version in.Building the engine from its own sources stopped at
API.Types:the same mismatch the repository-level constraint was added for, between
the plain
InsOrdHashMapthe schema code buildspropertieswith and thecompat newtype openapi3 3.2.5 wraps it in from that version on.
What was and was not affected
The published image never hit this.
volca-image.ymldownloads thereleased binary, checks it against
SHA256SUMS, and passes it as a buildcontext that shadows the
haskell-builderstage, so BuildKit resolvesCOPY --from=haskell-builderagainst that directory and never builds thestage. What was broken is the path that actually compiles: building the
image from source, and the image step of the deployment repository's
release gate.
The comment above the line now says why the constraint is repeated rather
than shared, so the next person does not delete it as a duplicate.
Verified by building the
haskell-builderstage through to a staticallylinked binary, which is what the stage's own check requires.