Support labels #1701
Support labels #1701
Conversation
carolynvs
force-pushed
the
labels
branch
4 times, most recently
from
ad28356 to
d960c9a
Compare
There was a problem hiding this comment.
My only other thought is around the use of a positional argument for the installation/paramset/credset name and how it is different from the other query options that are behind flags (--namespace and --label). I'm wondering if we want to consider using a flag for the name query (--name), instead of consuming it via the positional arg.
However, the installation/paramset/credset name is and has been consumed via a positional arg for the corresponding install and generate commands, so in this light, the current approach is in-line with expectations.
pkg/porter/list.go
Outdated
| if len(args) == 1 { | ||
| o.Name = args[0] | ||
| } else if len(args) > 1 { | ||
| return errors.Errorf("only one positional argument may be specified, the installation name, but multiple were received: %s", args) |
There was a problem hiding this comment.
Do we need this same check for the params/creds list commands?
e.g.
$ porter params list foo foo
NAMESPACE NAME MODIFIED
There was a problem hiding this comment.
I'll switch to a --name flag so that we don't need this check at all.
|
@vdice I actually ripped off the |
|
@vdice fixed |
Add labels to installations, credential sets and parameter sets. Signed-off-by: Carolyn Van Slyck <[email protected]>
Signed-off-by: Carolyn Van Slyck <[email protected]>
Signed-off-by: Carolyn Van Slyck <[email protected]>
What does this change
Support applying labels to installations, parameter and credential sets. Users can use these labels to filter list results. Eventually we can use these for matching dependencies.
I have also moved when an installation is created during porter install so that we can persist the labels.
What issue does it fix
Closes #1683
Notes for the reviewer
Checklist