packer

Commit Graph

Author	SHA1	Message	Date
anshulSharma	a234126747	changes for pulling binary from releases.hashicorp.com (#13431 ) * changes for pulling binary from releases.hashicorp.com * cahnges for getting release from release official site * cahnges for getting release from release official site * unit test cases * unit test cases * unit test coverage * changes for getter releases.hashicorp.com * lint fix * lint fix * lint fix * manifest.json related changes * manifest.json related changes * manifest.json related changes * manifest.json related changes * github getter test cases * added test cases for getters * added test cases for getters * added test cases for getters * added test cases for getters * added test cases for getters * added test cases for plugins getter * unit test cases for getting release from official site * description to the methods	7 months ago
Lucas Bajolet	b4a843c4e2	commands: reject constraints with pre-releases (#12999 ) When remotely installing a plugin, constraints are used by Packer to determine which version of a plugin to install. These constraints can be arbitrarily complex, including operators and ranges in which to look for valid versions. However, the versions specified in those constraints should always be final releases, and not a pre-release since we don't explicitly support remotely installing pre-releases. This commit therefore addds checks to make sure these are reported ASAP, even before the source is contacted to list releases and picking one to install.	2 years ago
Lucas Bajolet	c7f2508373	addrs: return error on ParsePluginSource The ParsePluginSource function can be invoked from either a HCL2 context (when parsing a required_plugins block), or from the command-line itself. While in the first context a hcl.Diagnostics is coherent, in case the source to parse is a command-line argument, for example when installing or removing a plugin, the error message cannot have an HCL context, leading to errors that are incorrectly prefixed by a <nil> string dure to the lack of a reference to attach the diagnostic to. Therefore, in order to fix this behaviour, the logic that parses plugin sources now returns an error, and attaching the error to an HCL subject is done independently, if needed.	2 years ago
Lucas Bajolet	b24ab44a55	command: list releases only for remote installs When installing a plugin from a remote source, we list the installed plugins that match the constraints specified, and if the constraint is already satisfied, we don't do anything. However, since remote installation is only relevant for releases of a plugin, we should only look at the installed releases of a plugin, and not consider pre-releases for that step. This wasn't the case before this commit, as if a prerelease version of a commit (ex: 10.8.1-dev), and we try to invoke `packer init` with a constraint on this version specifically, Packer would locate that pre-release and assume it was already installed, so would silently succeed the command and do nothing. This isn't the expected behaviour as we should install the final release of that plugin, regardless of any prerelease installation of the plugin. So this commit fixes that by only listing releases, so we don't report the plugin being already installed if a prerelease is what's installed.	2 years ago
Lucas Bajolet	6fc1d154bd	packer: relax constraints on sources The source parsing logic was heavily directed towards Github compatible source URIs, however if we want to support more cases, we need to make sure we are able to specify those URIs, and to load plugins installed from those sources. Right now, since the getters available are only github.com, we will not support remotely instlling plugins from sources other than github.com, with the same set of constraints as before. However, we do support now installing from a local plugin binary to any kind of source, and we support loading them, including if a template wants this plugin installed locally with version constraints.	2 years ago
Lucas Bajolet	d7f299886d	command: scrub metadata from version at install When installing plugins with the `packer plugins install --path' command, the metadata is now scrubbed from the file installed locally. This is as a protection against collisions in the versions, as metadata is meaningless for version comparison, so if two versions of the same plugin are installed, the precedence order between them is undefined. Therefore to avoid such collisions, we remove the metadata from the file name, that way if two successive versions of a plugin include metadata in the version, they won't coexist, and the last installed will be the only installed version locally.	2 years ago
Lucas Bajolet	3f721ff03e	cmd/plugin_install: use semver to render version When installing a plugin from a local binary, Packer builds the name of the plugin from the results of the `describe' command. Depending on how the plugin is built, the version reported may or may not contain a leading `v', which was not taken into account beforehand and the leading `v' was always injected in the path. This caused plugins that report a leading `v' in their version to be installed with two v's in their path, making them impossible to load. Therefore to fix this issue, we count on the version library to print out a version without the leading v, and we inject that in the resulting path.	2 years ago
Lucas Bajolet	503768c683	command: trim trailing spaces from help message	2 years ago
Lucas Bajolet	9a6e74a66b	command: add dev support for plugins install Since we now support loading pre-releases with Packer subcommands, we relax the contraints we had placed on the `--path' option, so it will accept any `-dev' binary, in addition to final releases.	2 years ago
Lucas Bajolet	4b00a81bf3	packer: remove directory slices from structs Since we'll only look in the plugin directory, and not from multiple sources now, for installing/listing plugins, we can simplify the structures which used to accept multiple directories so they only accept one.	2 years ago
Lucas Bajolet	94aaff44a1	packer: only support one directory for plugins Since we're removing the alternative plugin installation directories in favour of only supporting installing them in the PACKER_PLUGIN_PATH directory, we only return one directory when getting the known plugin directories.	2 years ago
Wilken Rivera	2241b1fba7	Update spacing for flags within Help text Before Change ``` Options: - path <path>: install the plugin from a locally-sourced plugin binary. This installs the plugin where a normal invocation would, but will not try to download it from a remote location, and instead install the binary in the Packer plugins path. This option cannot be specified with a version constraint. - force: forces reinstallation of plugins, even if already installed. ``` After Change ``` Options: -path <path> Install the plugin from a locally-sourced plugin binary. This installs the plugin where a normal invocation would, but will not try to download it from a remote location, and instead install the binary in the Packer plugins path. This option cannot be specified with a version constraint. -force Forces reinstallation of plugins, even if already installed. ```	2 years ago
Lucas Bajolet	97e2e9e637	docs: add exerpt on packer plugins install --path	2 years ago
Lucas Bajolet	8e2a22e583	command: simplify local binary installation Read original binary into memory to fix case when installation destination and source were the same, resulting in an empty binary.	2 years ago
Lucas Bajolet	e293f2d890	command: plugins install reject non-releases 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.	2 years ago
Lucas Bajolet	ae5b91864c	command: reject version with --path for install 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.	2 years ago
Lucas Bajolet	a2d9c9dce4	command: add --force option to init/install 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.	2 years ago
Lucas Bajolet	6f43a82e02	command: add packer plugins install path flag 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.	2 years ago
Lucas Bajolet	eb9e1a4795	packer: remove implicit required plugins Since this feature is no longer something we plan to activate later, as it contradicts with our efforts to remove bundled plugins, and encouraging users to move to either manually installing plugins, or managing them through `packer init', we clean-up the code for this feature.	3 years ago
hashicorp-copywrite[bot]	19055df3ec	[COMPLIANCE] License changes (#12568 ) * Updating the license from MPL to Business Source License Going forward, this project will be licensed under the Business Source License v1.1. Please see our blog post for more details at https://hashi.co/bsl-blog, FAQ at https://hashi.co/license-faq, and details of the license at www.hashicorp.com/bsl. * Update copyright file headers to BUSL-1.1 --------- Co-authored-by: hashicorp-copywrite[bot] <110428419+hashicorp-copywrite[bot]@users.noreply.github.com>	3 years ago
hashicorp-copywrite[bot]	b7df3ca36f	[COMPLIANCE] Add Copyright and License Headers (#12254 ) Co-authored-by: hashicorp-copywrite[bot] <110428419+hashicorp-copywrite[bot]@users.noreply.github.com>	3 years ago
Wilken Rivera	a7c37ee34d	Add tests for the packer plugins subcommand (#11660 ) * Add tests for plugins install command * Add tests for plugins remove command * Add PACKER_GITHUB_API_TOKEN to all test env * Update dir hashes for non-darwin os * Update tests with feedback from review	4 years ago
Wilken Rivera	ea3c73a480	Set default file extension for binary installations on Windows (#11625 ) This change sets the default file extension for binary installations on Windows. Results before change ``` $ packer plugins install github.com/hashicorp/amazon 9 errors occurred: * ignoring invalid remote binary packer-plugin-amazon_v1.0.8_x5.0_freebsd_arm64.zip: wrong system, expected windows_amd64 * ignoring invalid remote binary packer-plugin-amazon_v1.0.8_x5.0_darwin_amd64.zip: wrong system, expected windows_amd64 * ignoring invalid remote binary packer-plugin-amazon_v1.0.8_x5.0_freebsd_amd64.zip: wrong system, expected windows_amd64 * ignoring invalid remote binary packer-plugin-amazon_v1.0.8_x5.0_linux_amd64.zip: wrong system, expected windows_amd64 * ignoring invalid remote binary packer-plugin-amazon_v1.0.8_x5.0_darwin_arm64.zip: wrong system, expected windows_amd64 * ignoring invalid remote binary packer-plugin-amazon_v1.0.8_x5.0_windows_arm64.zip: wrong system, expected windows_amd64 * ignoring invalid remote binary packer-plugin-amazon_v1.0.8_x5.0_windows_386.zip: wrong system, expected windows_amd64 * ignoring invalid remote binary packer-plugin-amazon_v1.0.8_x5.0_linux_arm.zip: wrong system, expected windows_amd64 * could not find a packer-plugin-amazon_v1.0.8_x5.0_windows_amd64.zip file in zipfile exit status 1 ``` Results after change ``` $ packer plugins install github.com/hashicorp/amazon Installed plugin github.com/hashicorp/amazon v1.0.8 in "C:/Users/Packer/AppData/Roaming/packer.d/plugins/github.com/hashicorp/amazon/packer-plugin-amazon_v1.0.8_x5.0_windows_amd64.exe" ```	4 years ago
Adrien Delorme	9f4a1281dd	Add `packer plugins` command and subcommands to interact with plugins (#11553 ) * add basic docs for plugins command * refactor docs Co-Authored-By: Wilken Rivera <1749304+nywilken@users.noreply.github.com> * add plugins command * add plugins subcommands they do nothing for now * add plugins installed command + tests * add plugins install command * add remove plugin command * better docs for the plugins install command * remove duplicate content * better output for installed plugins * add plugins required command * Update plugins_install.go * add newline after `Usage:` * Update plugins_remove.go * Update plugins_required.go * Update plugins_remove.go * Update plugins_installed.go * Update plugins_install.go * add docs * Update plugins_install.go * fix typos * Update plugins_test.go * fix typos Co-Authored-By: Wilken Rivera <1749304+nywilken@users.noreply.github.com> * Update core_wrapper.go Co-Authored-By: Wilken Rivera <1749304+nywilken@users.noreply.github.com> * Update website/content/docs/commands/plugins/remove.mdx Co-authored-by: Wilken Rivera <wilken@hashicorp.com> * Update website/content/docs/commands/plugins/required.mdx Co-authored-by: Wilken Rivera <wilken@hashicorp.com> * Update website/content/docs/commands/plugins/required.mdx Co-authored-by: Wilken Rivera <wilken@hashicorp.com> * Update plugins_required.go * Update install.mdx * Update required.mdx * plugins requirement, warn when no plugin was found * Update website/content/docs/commands/plugins/required.mdx Co-authored-by: Wilken Rivera <wilken@hashicorp.com> Co-authored-by: Wilken Rivera <1749304+nywilken@users.noreply.github.com> Co-authored-by: Wilken Rivera <wilken@hashicorp.com>	4 years ago

24 Commits (52448da979a008c8b8d8828af9efa526fd10a302)