Add support for additional tags #802
Conversation
Codecov Report
@@ Coverage Diff @@
## main #802 +/- ##
==========================================
+ Coverage 67.80% 67.92% +0.11%
==========================================
Files 112 112
Lines 4846 4863 +17
==========================================
+ Hits 3286 3303 +17
Misses 1191 1191
Partials 369 369
Continue to review full report at Codecov.
|
| @@ -5,7 +5,8 @@ kpack will monitor the inputs to the image configuration to rebuild the image wh | |||
|
|
|||
| The following defines the relevant fields of the `image` resource spec in more detail: | |||
|
|
|||
| - `tag`: The image tag. | |||
| - `tag`: The image tag. This is the primary image tag that is immutable for a given image and is re-used during subsequent builds for certain cached data. | |||
| - `additionalTags`: Any additional list of image tags that should be published. This list of tags is mutable. | |||
There was a problem hiding this comment.
I am a bit conflicted if we should only allow additional tags to be tag names or fully fledged docker image tags. The former would be easier in terms of secret management etc. and ensuring that pushes succeed where as the latter would be more flexible. I am tempted to switch to the former but I have currently implemented the latter.
There was a problem hiding this comment.
The docker terminology around tags makes this quite cumbersome. We really want to just provide a mechanism to add additional tags to the same repo but, the kpack api has used the term tag to reference the entire image name (similar to --tag on docker build). It would be ideal if we had a terminology to provide just a list of simple tags.
There was a problem hiding this comment.
Should we call it additionalRefs?
There was a problem hiding this comment.
Maybe? Ref sounds like it might be referring to another kubernetes resource.
There was a problem hiding this comment.
This seems relevant: buildpacks/community#128
|
@matthewmcnew ping on reviews for this PR. This would be really helpful for our use cases. |
| @@ -89,6 +90,10 @@ func (is *ImageSpec) validateTag(ctx context.Context) *apis.FieldError { | |||
| return validate.Tag(is.Tag) | |||
| } | |||
|
|
|||
| func (is *ImageSpec) validateAdditionalTag(ctx context.Context) *apis.FieldError { | |||
There was a problem hiding this comment.
Should we validate that the tags are valid "tags" in the same registry similar to the lifecycle?
|
I was originally a bit reluctant to allow kpack Images to have mutable tags because I feared it would encourage the referencing images over digests. I think I have come around to it. My only hesitation is the complication in modeling it in the api. (eg. including |
sambhav
force-pushed
the
additional-tags
branch
from
f04d524 to
7174624
Compare
Signed-off-by: GitHub <noreply@github.com>
sambhav
force-pushed
the
additional-tags
branch
from
7174624 to
4aa9197
Compare
|
@matthewmcnew this is ready for a review |
|
@matthewmcnew can we merge this? |
|
@samj1912 We plan on merging today. Thank you for your patience :) |
Adds support for additional tags to be specified as a part of the image spec. This would allow users to manually patch and specify additional tags to be pushed out. This can allow kpack users to push semver tags or other tags like git commit shas by a utility like
kp cli.Example use cases -
kp image save --additional-tag myimage:v1.2 --additional-tag myimage:$(git rev-parse HEAD)where the above would override the additionalTags array entirely with the newly supplied values
to patch and tag images with commit shas or version numbers.
Fixes #802 and possibly #755