-
Notifications
You must be signed in to change notification settings - Fork 96
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
fix package policy secrets #821
Conversation
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.
Can we add some unit tests around these two functions to capture both these formats?
can do |
I'm not even sure if all these test combinations will even show up, but they pass :D Even found an undesirable edge case that pops up with imports/0.11.8 migrations and unknown secrets. |
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.
Thanks for following up with this :)
* origin/main: fix package policy secrets (#821) chore(deps): update codecov/codecov-action digest to b9fd7d1 (#815) Bump release memory Switch to golang 1.23.2 in release Bump release memory Prepare release v0.11.8 (#810) Add key_id as an explicit attribute (#789) standalone-output resource (#811) Add URL support to data_view field_formats (#812) migrate fleet integration_policy to framework, fix secret churn (#797) Allow mappings to be unknown to support mappings defined in index templates (#803)
I migrated work to 0.11.8, and any secret refs were removed in the state after apply.
During testing, it looked like responses either came in the format of
{"k1": "v1", ...}
or{"k1": {"type": "string", "value": "v2"}, ...}
. Any time a secretRef was seen, it was inside the latter format. Apparently they can also show up in the former. This fixes the oversight, unit test didn't catch it :(