iSharkFly-Docs
/
packer-cn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Update with suggestion from review

This commit is contained in:
Wilken Rivera 2021-02-10 10:37:24 -05:00
parent 926e287025
commit 4e2d2961b6
2 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
website/content/docs/commands/init.mdx
View File

@ -58,7 +58,7 @@ HashiCorp does not officially verify third party Packer plugins, plugins not und
## Plugin Selection
Plugin selection depends on the source and version constraints defined within the `required_plugins` block.
For each of the required plugins Packer will query the source repository `azr/myawesomecloud` whose fully qualified address
is `https://github.com/azr/packer-plugin-myawesomecloud` for a plugin matching the version constraints for the host Os.
is `https://github.com/azr/packer-plugin-myawesomecloud` for a plugin matching the version constraints for the host operating system.
Packer init will install the latest found version matching the version selection
in the `required_plugins` section. Make sure to set a correct [version

4
website/content/guides/1.7-plugin-upgrade/index.mdx
View File

@ -152,7 +152,7 @@ Then you'd install it by putting it into the plugin directory with the name `pac
With the multi-plugin binary you would then refer to your newly installed plugin as `bar-foo` within your Packer template. Whereas, in the single binary setup, you'd have used the name "bar" in your Packer template.
At this point it is important to note that multi-plugins are to Packer, what providers are to Terraform. Multi-plugin binaries are meant to provide one or more plugin types to Packer which depend on the same cloud or other APIs. See [registering multiple plugins](#registering-multiple-plugins) for details on how to register more than one plugin type.
At this point it is important to note that multi-plugins are to Packer, what providers are to Terraform. Multi-plugin binaries provide one or more plugin types to Packer which depend on the same cloud or other APIs. See [registering multiple plugins](#registering-multiple-plugins) for details on how to register more than one plugin type.
If your plugin providers a single plugin type please continue reading for instruction on using the Set architecture for single plugins.
@ -203,4 +203,4 @@ You can still use the `DEFAULT_NAME` constant with a set implementation; in this
## Distributing migrated plugins
Once a plugin has been migrated to use the `packer-plugin-sdk` it can be released as it normally would and used by Packer by [installing the plugin](/docs/plugins#installing-plugins) manually into the respective Packer plugin directory.
If however, you would like to take advantage of Packer's automated plugin installation process via `packer init` -- the preferred method of installation -- you will need to make the plugin available on GitHub and in a repository named after the multi-plugin `https://github.com/<yourorg>/packer-plugin-<name>`. See [Creating a GitHub Release](/docs/plugins/creation#creating-a-github-release) for details on the recommended practice for releasing Packer plugins on GitHub.
If however, you would like to take advantage of Packer's automated plugin installation process via `packer init` -- the preferred method of installation -- you will need to make the plugin available on GitHub and in a repository named after the multi-plugin `https://github.com/<yourorg>/packer-plugin-name`. See [Creating a GitHub Release](/docs/plugins/creation#creating-a-github-release) for details on the recommended practice for releasing Packer plugins on GitHub.