-
Notifications
You must be signed in to change notification settings - Fork 695
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
Add SealedSecret 'template' to use when constructing Secret #180
Conversation
fcf547d
to
68631a2
Compare
This change adds a `spec.template` to the SealedSecrets schema, which includes `metadata` and `type` used when constructing the new Secret. (All the Secret fields _other_ than `data`/`encryptedData`) Also this change adds: - Events to the SealedSecret describing progress/errors while unsealing. - A SealedSecret `status` structure that exposes overall success/failure. Fixes #92 Fixes #72
bors r+ |
👎 Rejected by too few approved reviews |
bors r+ based on a very superficial review 🤞 |
🔒 Permission denied Existing reviewers: click here to make atomatt a reviewer |
bors delegate=atomatt |
✌️ atomatt can now approve this pull request |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
very superficial review, mostly to please bors.
bors r+ |
180: Add SealedSecret 'template' to use when constructing Secret r=atomatt a=mkmik Merge #129 into current codebase (which as diverged in the meantime) ``` This change adds a spec.template to the SealedSecrets schema, which includes metadata and type used when constructing the new Secret. (All the Secret fields other than data/encryptedData) Also this change adds: Events to the SealedSecret describing progress/errors while unsealing. A SealedSecret status structure that exposes overall success/failure. ``` Fixes #92 Fixes #72 Co-authored-by: Angus Lees <gus@inodes.org> Co-authored-by: Marko Mikulicic <mkm@bitnami.com> Co-authored-by: Christopher Harm <crh5255@psu.edu>
Build succeeded |
Could be labelled as 0.8.0 as well :) |
To avoid overcrowding the milestone "changelog" I tended to favour labelling tracking issues (such as #92 in this case) over PRs. My mind can easily be changed with arguments :-) |
@mkmik I had the opposite practice as it allows to track which work get into which milestone, after several years I found it useful. But your point is just as fine it just address different concerns ;) |
Merge #129 into current codebase (which as diverged in the meantime)
Fixes #92
Fixes #72