crane label and crane annotate

[imjasonh]

crane label my-image \
  --label a=b \
  --label b=c
  --new_ref=my-image:labeled

The --new_ref flag is optional, and if omitted, crane label would tag over my-image.

This would necessitate a new mutate.Labels(v1.Image) method to mirror mutate.Annotations(v1.Image) being proposed in #960

This 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.

[jonjohnsonjr]

Something dumb like --unlabel a?

[jonjohnsonjr]

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 crane mutate or something?

[jonjohnsonjr]

This would necessitate a new mutate.Labels(v1.Image) method

We can do this today with mutate.Config.

[imjasonh]

Something dumb like --unlabel a?

Love it.

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 crane mutate or something?

I'm fine that. Were you imagining crane mutate as a subcommand for other subcommands (crane mutate label and crane mutate annotations) or as a place to do a bunch of mutations (crane mutate --label a=b --annotation b=c) ?

We can do this today with mutate.Config.

Yep, good call.

[jonjohnsonjr]

Were you imagining crane mutate as a subcommand for other subcommands

Yeah this one seems easiest but there's a lot of interesting things we could do with a generic mutate command.

[imjasonh]

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 crane mutate and see how we like it.

Since it's all composable it should also work to do:

crane mutate label -l a=b $(crane mutate annotation -a b=c)

But that's a lot grosser than:

crane mutate label -l a=b -a b=c

And that second one wouldn't have to produce new intermediate manifests in the registry, which is nice.

[otaviof]

Hello 👋🏼 !

What do you think about a mixed approach? I like the ability to crane mutate ... labels and annotations at once. So, my suggestion is the following:

# 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 mutate, I think we should let users inform the behavior by inspecting the actual flags, as in --[un]label and --[un]annotate. For instance:

# 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

[imjasonh]

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.

[imjasonh]

Closing in favor of the older #281