Document the process for registering a plugin as an integration #108
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The Packer integration framework requires that all plugin integrations follow a consistent documentation structure. The structure outlined below requires a single top-level README.md for the integration, and one README.md file per component offered by the integration. Any shared documentation such as authentication, guides, common plugin practices should be captured with the top-level integration README. Component specific READMEs should only contain information related to the component. ``` docs ├── README.md #top-level integration README - main entry point at https://developer.hashicorp/packer/integrations └── components ├── builder # builder component types │ └── name # named component (e.g docker) │ └── README.md ├── datasource │ └── name # named data source (e.g http) │ └── README.md ├── post-processor │ └── name │ └── README.md └── provisioner └── name └── README.md ```
This change adds the controlling metadata.hcl file needed for registering a plugin as a Packer integration. The example metadata.hcl file has been updated to reflect the components within the scaffolding template. In additional to the controlling metadata file the two integration release workflows have been added to show case how a plugin integration can be used manually and automatically via a release.
README.md
Outdated
| Once the first `docs.zip` file has been included into a release you will need to open a one time pull-request against [hashicorp/packer](https://github.com/hashicorp/packer) to register the plugin docs. | ||
| Registering a plugin as an integration requires [metadata configuration](./metadata.hcl) within the plugin | ||
| repository and approval by the Packer team. To initiate the process of registering your | ||
| plugin as a Packer integration refer to the [Developing Plugins](https://developer.hashicorp.com/docs/packer/plugins/creation) page. |
There was a problem hiding this comment.
I presume this will be created soon as well? The link is dead for now
There was a problem hiding this comment.
There's a typo in the link. I will fix that.
|
Coming back on this, we should probably add some partials to the example docs, so users that adopt it will see how they're used. |
I've created a new issue to track this. I think that would be a good follow up PR. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The Packer integration framework requires that all plugin integrations follow a consistent documentation structure. The structure outlined below requires a single top-level README.md for the integration, and one README.md file per component offered by the integration.
Any shared documentation such as authentication, guides, common plugin practices should be captured with the top-level integration README. Component specific READMEs should only contain information related to the component.