provenance: add dockerfile frontend version#6705
Conversation
| } | ||
| pr.BuildDefinition.InternalParameters.DockerfileVersion = dockerfileVersion | ||
| } | ||
|
|
There was a problem hiding this comment.
This reminds me of recent changes in #6643
Was thinking it would not read the builtin version if we route to builtin but seems to work. Also next commit covers this case ee145d2#diff-b9582afb7cee482a23201365d6a87e962b706b6fe027b091c5d4094e3bbba796R1073
| if dockerfileVersion := dockerfileversion.Version(); dockerfileVersion != "" { | ||
| buildkitVersion.DockerfileVersion = dockerfileVersion | ||
| } |
There was a problem hiding this comment.
Hum I was looking at
buildkit/cmd/buildkitd/main.go
Line 818 in 29dc132
Would prinjt the Dockerfile version in buildctl debug info for a daemon that cannot serve the builtin Dockerfile frontend. Should we follow actual frontend registration?
There was a problem hiding this comment.
This is probably fine and could be considered a compatibility version, not an indication that the frontend is enabled. It's not very clean to update this for the listworkers code path.
Record the builtin Dockerfile frontend version in provenance attestations for both SLSA v0.2 and v1 formats. The version is derived from a new builder.Version constant, normalized with the BuildKit release version suffix. The external frontend Dockerfile validates that the builtin version constant matches the git tag at release time. Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Expose the builtin Dockerfile frontend version in BuildKit version APIs and buildctl debug output. Move Dockerfile version logic into frontend/dockerfile/version and validate that the builtin version constant matches release tags. Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
ee145d2 to
1890989
Compare
|
🤦 Forgot to merge this for v0.30.0-rc1 |
depends on #6681
Record the builtin Dockerfile frontend version in provenance
attestations for both SLSA v0.2 and v1 formats. The version
is derived from a new builder.Version constant, normalized
with the BuildKit release version suffix.
The external frontend Dockerfile validates that the builtin
version constant matches the git tag at release time.
The Dockerfile version file needs to be updated after release branch is cut or on Dockerfile patch releases. Note that we can't use dockerfile git version tags for this as buildkitd is tagged before Dockerfile version and has it's own version that is different.