-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Feat: Multiple registry projects #815
Feat: Multiple registry projects #815
Conversation
Thanks for the PR! 🚀 |
/gcbrun |
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.
For backwards compatibility, could you keep the existing registry_project_id
as well? (Otherwise we'll have to wait until next major release.)
Sure. I'm thinking that I could rename the Alternatively, not renaming the new |
Right, that's what I had in mind. |
@morgante The requested changes have been made. I've added the Once this PR is merged, I'll create another one that will actually remove the |
In our organization, we have a few projects that we put container images into depending on the team, and sometimes a cluster needs access to more than one of them. Right now we use a custom module that isn't a wrapper for this one, but I'd like to change that. This PR would allow that to happen, but it does mean a breaking change for those who utilize the variable as it is currently defined.
I've also updated the tests to handle the change of the variable name from
registry_project_id
toregistry_project_ids
and the type now beinglist(string)
. Theworkload-metadata-config-local
integration test (the only test to reference the formerregistry_project_id
variable) passes locally as well. That being said, I've not used InSpec before and am not 100% sure everything's correct regarding my changes, so if it's decided that this PR merits inclusion, I'd appreciate a closer look at that part of the PR just to make sure nothing's broken.