Backport of Document process for registering a plugin as a Packer Integration into release/1.10.x #12746
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
This reverts commit cc22e28. The action successfully works now for the future release branch.
* Updates cloud-resource-management API to use sable * Removes duplicate imports of the same SDK packages
Bumps [github.com/hashicorp/hcp-sdk-go](https://github.com/hashicorp/hcp-sdk-go) from 0.73.0 to 0.74.0. - [Release notes](https://github.com/hashicorp/hcp-sdk-go/releases) - [Changelog](https://github.com/hashicorp/hcp-sdk-go/blob/main/CHANGELOG.md) - [Commits](hashicorp/hcp-sdk-go@v0.73.0...v0.74.0) --- updated-dependencies: - dependency-name: github.com/hashicorp/hcp-sdk-go dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
When a user invokes packer for a build or validation, the template being processed needs components to be present for Packer to process it without error. If the component cannot be found from the plugins loaded (or from the components bundled with Packer), Packer errors, and the command fails. This is expected, but the error message does not suggest anything to fix the error, potantially leaving users confused at the problem. This commit suggests either a replacement (in case of a typo), or points to the web documentation for Packer, specifically the integrations, so they can look for the plugin they're missing, and install it, so subsequent invocations of Packer work.
This change initializes a MapOfBuilders with the test builder to fix a panic with checking if the initialized BuilderSet has an entry for the test builder.
If a variable is defined and overriden in the packer command-line, but there's a problem during the evaluation of this override (type error typically), we show an error message which details the problem. This message points to a temporary in-memory HCL2 "file" that we use for parsing and evaluating the expression for the variable, but since it's virtual, there's no point in using this as the source for the error, as it will always yield "line 0" and no contents. So, in order to limit confusion here, we remove the source for this error message.
cty's new "refinements" concept allows us to reduce the range of unknown values from our functions. This initial changeset focuses only on declaring which functions are guaranteed to return a non-null result, which is a helpful baseline refinement because it allows "== null" and "!= null" tests to produce known results even when the given value is otherwise unknown. This commit also includes some updates to test results that are now refined based on cty's own built-in refinement behaviors, just as a result of us having updated cty in the previous commit.
In order to better document packer plugins installation methods, and since `packer plugins install' is not really manual, we split in two sections the "manual installation". As this is legacy, we stop documenting how to install single-component plugins, and reword the documentation for manually installing a plugin.
This section is redundant with the explanations given above, and can therefore be removed from the docs.
The current documentation about installing plugins does not explain (outside of the `packer init' section) how Packer discovers plugins, what the expected file system hierarchy should be, and the quirk of how this takes precedence over the rest when `required_plugins' is specified. This commit addresses that by reorganising the page to highlight general usage questions on sources and plugins, and simplifies the tabs below to only highlight installation methods.
This new flag allows the `packer plugins install' command to install a plugin from a local binary rather than from Github. This command will only call `describe' on the plugin, and won't do any further checks for functionality. The SHA256SUM will be directly computed from the binary, so as with anything manual and potentially sourced by the community, extra care should be applied when invoking this.
The --force option for packer init and packer plugins install enforces installation of a plugin, even if it is already locally installed. This will become useful if for some reason a pre-existing plugin binary/version is already installed, and we want to overwrite it.
To avoid plugins being installed with a specific version when a path is used for installing a plugin from a locally sourced plugin binary, we explicitly reject the combination of both a path and a version for plugins install.
When installing a plugin with packer plugins install --path, we only accept release versions of a plugin, as otherwise the loading can be inconsistent if for example a user specifies a required_plugins block in their template, in which case the plugins will be ignored. Until we have a simpler loading scheme then, we will reject non-release versions of plugins to avoid confusion.
Read original binary into memory to fix case when installation destination and source were the same, resulting in an empty binary.
This change removes the following plugins from the old docs framework, as they have been fully migrated to the integrations framework. * ethanmdavidson/packer-plugin-git * linode/packer-plugin-linode * parallels/packer-plugin-parallels * ivoronin/packer-plugin-sshkey * cirruslabs/packer-plugin-tart
The plugins installed command list installed plugins, and prints out all their paths and versions. The results are listed in a list of unique versions, in ascending order. When listing plugins outside of a specific identifier however, because of the insertion in the list works, we only consider the version number, and ignore all subsequent insertions with the same version. This causes a problem when we have multiple plugins installed with the same version, as only the first one that is discovered (typically the one with lexicographical precedence) gets inserted, and the others are ignored. To support such a use case, we change the insertion routine to not only support versions, but also paths when finding a spot to insert the installation into.
…opeful-seagull
hc-github-team-packer
force-pushed
the
backport/update/plugin-integration-docs/properly-hopeful-seagull
branch
from
50d2d82
to
27acc66
Compare
|
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. |
lbajolet-hashicorp
deleted the
backport/update/plugin-integration-docs/properly-hopeful-seagull
branch
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Backport
This PR is auto-generated from #12702 to be assessed for backporting due to the inclusion of the label backport/website.
The below text is copied from the body of the original PR.
Original PR had no description content.
Overview of commits