-
Notifications
You must be signed in to change notification settings - Fork 24
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 post-processor for HCP Vagrant Box Registry #122
Conversation
359d439
to
4590398
Compare
4590398
to
07ef8ec
Compare
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.
Overall this looks good to me. I left a comment about the needed to have an argument for a project_id in the pps config.
be semver, and doesn't validate that the version comes after your previous | ||
versions. | ||
|
||
- `client_id` (string) - The service principal client ID for the HCP API. This |
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.
Packer relies on these environment variables for connecting to HCP Packer. Normally, a user will set HCP_CLIENT_ID, HCP_CLIENT_SECRET, and HCP_PROJECT_ID when publishing an artifact to HCP Packer or reading an image from HCP Packer.
Vagrant doesn't have support for HCP project ID but if this post-process was used in environment where these envs are defined would the value of Project ID affect authentication?
I think if using an org level service principal that can pull an image from HCP Packer to use as the source for VMware that then uses Vagrant to create a box, and publish to vagrant registry inside a different project. The user would need the ability to set a project ID.
If using project level sec principles then they would still need to provide a project id if HCP Packer registry and Vagrant registry are not in the same project.
project_id should be added as an optional configuration argument.
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.
The organization/project values don't have any effect on the vagrant service API being used here. There is a limited set of API end points that use organization/project values, and they are outside of the scope of any interactions this plugin would have with the service (they are specifically related to the top-level registry management tasks).
The SDK will apply the organization/project values to requests if they are unset and the requests expect those values. Since none of the requests here use them, even if the values are set they will never be used. I'm happy to add them as config options but any provided values would not be used (or enforced).
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.
Got it. No need to add the config. I thought it might be a problem. I confirmed all works as expected.
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.
This looks good to me. Nicely done, and thank for the additional context on the Project ID.
Hi! This PR adds a new post-processor (
vagrant-registry
) for publishing vagrant boxes to the Vagrant box registry on HCP. The configuration and behavior of the post-processor closely matches that of the Vagrant Cloud post processor to require as little modification as possible for existing build templates.Also includes a new doc page for the post-processor (based on the
vagrant-cloud
post-processor page with updates where needed).