-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support run image rebase based on semver tags #391
Comments
@loewenstein this makes sense to me. Could you suggest some alternate language for the spec? |
I guess it needs a spec and a lifecycle change. If we do not detect semver via heuristic, we could allow builder metadata to indicate semver based tags in run image metadata. WDYT? |
@natalieparellano where is the file format layed out in https://buildpacks.io/docs/reference/config/builder-config/ actually specified? |
I agree there are times when it's valid to rebase from one tag to another, and that the spec (and lifecycle/pack) implementations should allow for rebasing to different tags in cases where the operator knows they are compatible. However, I think: Something simpler that would solve both of these, would be to instead add support for overriding the tag/image name checks entirely, and providing a completely new image name/tag to be used as the rebase target (with suitable warnings that it's up to the user/operator to ensure the two images are ABI compatible). For example |
If I am not mistaken, then this is already supported with
With this, I agree, it should be possible for version schemes that express compatibility - independent of the number of digits a versioning scheme has. Would you have something specific in mind besides If it is basically those two versions, we might be able to get something like [[run.images]]
image: run-exact:latest
rebase: exact
[[run.images]]
image: run-semver:1.2.3
rebase: semver
[[run.images]]
image: run-range:1.2
rebase: range
range: <2.0 WDYT? |
@edmorley do you have a concrete versioning scheme in mind other than semver. If it is widely used it could be added to the proposed If there is nothing concrete now, I would propose to go with |
Right now the spec prohibits an update from e.g.
run:1.1
torun:1.2
(unlessforce: true
is used) , with this statementThis breaks reproducible builds (and rebases), because it enforces to use a floating tag run image in the
builder.toml
.While I can see value in preventing accidental rebases from e.g.
ubuntu:22.04
toubuntu:24.04
based run images, it is a severe limitation for stacks (aka build and run images) that use semver properly and would represent the example asrun:1.1
being based onubuntu:22.04
and then of course going forrun:2.0
for anubuntu:24.04
bump.See also the discussion on Slack.
The text was updated successfully, but these errors were encountered: