-
Notifications
You must be signed in to change notification settings - Fork 542
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
crane label
and crane annotate
#974
Comments
Something dumb like |
One concern I have is an explosion of top-level commands that do various things. Maybe not a huge deal, but small mutations like this might be lump-able under |
We can do this today with |
Love it.
I'm fine that. Were you imagining
Yep, good call. |
Yeah this one seems easiest but there's a lot of interesting things we could do with a generic mutate command. |
Since we've got two pretty easy ones lined up, maybe let's think about putting them in one Since it's all composable it should also work to do:
But that's a lot grosser than:
And that second one wouldn't have to produce new intermediate manifests in the registry, which is nice. |
Hello 👋🏼 ! What do you think about a mixed approach? I like the ability to # add or remove labels, using "label" and "unlabel" sub-commands
crane label image a=b c=d
crane unlabel image a c The same goes for annotations, with: crane annotate image e=f
crane unannotate image e As for # setting both labels and annotations with "mutate" sub-command:
crane mutate image --label a=b --label c=d --annotate e=f
crane mutate image --unlabel a --unlabel c --unannotate e |
I think I'd prefer to have one way to label/annotate, to reduce code/docs/tests needed. A CLI that can set multiple labels can also be used to set one, if you want to do it in multiple calls for whatever reason. |
Closing in favor of the older #281 |
The
--new_ref
flag is optional, and if omitted,crane label
would tag overmy-image
.This would necessitate a new
mutate.Labels(v1.Image)
method to mirrormutate.Annotations(v1.Image)
being proposed in #960This would add or overwrite existing labels/annotations only, and wouldn't facilitate unsetting existing values. I'm not sure whether that's a priority. Perhaps we could interpret
--label a=
to mean "unset", or--label a=<unset>
as a sentinel value. Setting the value to an empty string and unsetting the value are notably separate things.The text was updated successfully, but these errors were encountered: