-
Notifications
You must be signed in to change notification settings - Fork 179
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
refactor: change generic secret label #3331
refactor: change generic secret label #3331
Conversation
Signed-off-by: Kent Rancourt <kent.rancourt@gmail.com>
Signed-off-by: Kent Rancourt <kent.rancourt@gmail.com>
Signed-off-by: Kent Rancourt <kent.rancourt@gmail.com>
✅ Deploy Preview for docs-kargo-io ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3331 +/- ##
==========================================
+ Coverage 52.05% 52.53% +0.48%
==========================================
Files 295 291 -4
Lines 26695 26586 -109
==========================================
+ Hits 13895 13968 +73
+ Misses 12041 11855 -186
- Partials 759 763 +4 ☔ View full report in Codecov by Sentry. |
27c0c77
to
c02a5f8
Compare
…in v1.4.0 Signed-off-by: Kent Rancourt <kent.rancourt@gmail.com>
c02a5f8
to
77cab9e
Compare
As part of this, let's also get rid of |
@jessesuen there are spots in the code where we list only Secrets or ConfigMaps that have that label. When building an AnalysisRun we also refuse references to any ConfigMap or Secret not labeled in that way. Can you clarify for me how you want those behaviors to change? Are we simply eliminating those constraints? Or, more likely, are we eliminating that constraint for ConfigMaps and for Secrets, we will require the new generic cred label instead? |
It must not be enforced with the Job metric. In other words, I can currently create a job that references a secret to be used as an env var, and it currently works. So the label is not really fulfilling it's purpose, if that was the intent. |
My apologies. I was a bit hasty in my analysis of where this was used and I mis-identified a chunk of code that referenced that label. This is used exclusively by API endpoints that don't appear ever to have been used. So that label can go away easily. |
…mplate label Signed-off-by: Kent Rancourt <kent.rancourt@gmail.com>
Signed-off-by: Kent Rancourt <kent.rancourt@gmail.com>
Signed-off-by: Kent Rancourt <kent.rancourt@gmail.com> (cherry picked from commit 95ae6a6)
Successfully created backport PR for |
Signed-off-by: Kent Rancourt <kent.rancourt@gmail.com>
Signed-off-by: Kent Rancourt <kent.rancourt@gmail.com> Signed-off-by: Aidan Rowe <aidan@canva.com>
Signed-off-by: Kent Rancourt <kent.rancourt@gmail.com> Signed-off-by: Aidan Rowe <aidan@canva.com>
@jessesuen @gdsoumya this PR changes the label used to indicate a Secret is a generic one as discussed offline.
New Secrets get created with the new label.
To not break backwards compatibility with v1.2.0, updates will swap the legacy label for the new one and list operations will list all Secrets labeled with one or both.
There is a small breaking change, which will be documented in the release notes:
Expressions now have access only to appropriately labeled Secrets. That should have been included in #2975, but was accidentally overlooked.