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
Plugin selection depends on the source and version constraints defined within the `required_plugins` block. 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 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 Packer init will install the latest found version matching the version selection
in the `required_plugins` section. Make sure to set a correct [version 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. 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. 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 ## 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. 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.