feat: Add function set-standard-labels
#930
Conversation
yuwenma
force-pushed
the
set-standard-labels
branch
3 times, most recently
from
7efdc4b to
8aa6986
Compare
yuwenma
changed the title
set-standard-labels
yuwenma
force-pushed
the
set-standard-labels
branch
from
8aa6986 to
793eefd
Compare
yuwenma
force-pushed
the
set-standard-labels
branch
from
793eefd to
f218c94
Compare
| AppComponent = AppLabelPrefix + "component" | ||
| AppPartOf = AppLabelPrefix + "part-of" | ||
| AppManagedBy = AppLabelPrefix + "managed-by" | ||
| ) |
There was a problem hiding this comment.
May be we can call the function set-app-labels since it's too specific to setting application labels.
| type SetStandardLabels struct { | ||
| forDeployment string | ||
| // TBD: validate whether the recommended labels from the ResourceList.Items are set as expected. | ||
| validateOnly bool |
There was a problem hiding this comment.
Would be nice to have a separate function (or just have the same function aliased) with validate-app-labels will be nice.
| } | ||
| pkgName := kptfile.GetName() | ||
|
|
||
| // Assign blueprint pkg name to "app.kubernetes.io/name" and deployment pkg name to "app.kubernetes.io/instance" |
There was a problem hiding this comment.
When I was exploring argocd, this label was being used by argocd also for apps. Would be good to check if how well will it will play with argocd etc given that most of the users we are seeing are using kpt with argocd.
| if len(forDeployments) == 0 { | ||
| return false | ||
| } | ||
| return true |
There was a problem hiding this comment.
will be nice to have helper function in the SDK for this.
| // that follows some kpt specific conventions: | ||
| // - "app.kubernetes.io/name" comes from the current blueprint package name, or (if current is deployment) the upstream blueprint package. | ||
| // - "app.kubernetes.io/instance" is only set for deployment package, using its package name. | ||
| func (r *SetStandardLabels) Run(ctx *fn.Context, _ *fn.KubeObject, items fn.KubeObjects, results *fn.Results) bool { |
There was a problem hiding this comment.
Do you plan to support a bit more flexible input format where label value can be sourced from any field ? or that fits better in regular set-labels ?
Pending on dependent PRs
set-labelsto be importable #929TODO:
write README, setup new fn release workflow