As we're trying to move away from gob for serialising data over the
wire, this commit adds the capability for Packer to pick dynamically
between gob or protobuf for the serialisation format to communicate with
plugins.
As it stands, if all the plugins discovered are compatible with
protobuf, and we have not forced gob usage, protobuf will be the
serialisation format picked.
If any plugin is not compatible with protobuf, gob will be used for
communicating with all the plugins that will be used over the course of
a command.
The plugin and plugins command had a name that was close, and while
plugin is not supposed to be directly called by Packer users, this could
happen by accident while trying to execute packer plugins subcommands,
and when it does, the error messages are far from explicit, so unless
they understand what Packer is doing here, they'll likely be lost.
To reduce the risk of confusion, we rename the command to run packer
embedded components as execute.
* 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>
This change introduces the new actions-set-product-version, a tiny, but mighty, GitHub action that acts as a bridge between the product repo and our new CRT feature: automated version bumping.
tl;dr automated version bumping has a new command (bob update version) in the bob CLI that automatically bumps the version to a new patch. This automation has been introduced to crt-workflows-common as a new workflow (with the new bob command) and handles version bumping at the end of the release pipeline (after being released to production); for example, 1.0.0→1.0.1 and 1.0.0-dev→1.0.0. Bumping the minor version (ie 1.0.x→1.1.0) is only supported manually via bob update version -bump minor, but not supported in CRT (this work is upcoming). This is made possible by adding the new event “bump-version” in the ci.hcl file in this PR.
What this small action does:
Allows for the static version string from the version/VERSION file to be read by the new CRT workflow and automagically be bumped to the next version (whether it be a minor, or patch, or major version bump).
Outputs an error if there’s no VERSION file in the version dir
Outputs an error if there’s no version string in the VERSION file
Is able to parse product_version if it is 1.3.0-alpha1 as 1.3.0 (example: when product_version = 1.3.0-alpha1, base_version = 1.3.0)
Is able to parse prerelease product versions such as alpha1 (example prerelease_product_version = alpha1) in the statement above.
The latest release of the Oracle plugin for Packer removed
Solaris from its list of supported platforms. Since Packer still
releases binaries for Solaris the Oracle plugin will no longer be
bundled and distributed within the Packer binary. Practitioners relying
on the plugin can continue using the plugin by installing it manually
using either the `packer init` or `packer plugins install` commands.
This change updates Packer core Go version to 1.18. The move to Go 1.18 and not Go 1.19
is to allow the HCP Packer SDK time to upgrade to Go 1.18.
Changes Made:
* Bump go mod file to use Go 1.18
* Bump release pipeline to use Go 1.18
* Update plugin updater script to run go mod tidy for Go 1.18
* Update Linux job to use setup-go action
* Bump versions for all recently plugins
This change brings all plugins in Packer core up to date to address
issues with legacy SSH RSA-SHA1 key algorithms.
Related to: https://github.com/hashicorp/packer/pull/11761
* Update repository for packer-plugin-outscale
* Upgrade plugins to latest working versions
* Update accetest to work with new AMIHelper
* More updates
* More plugin updates
* bump MANY plugins at once !
* up docker plugin && go mod tidy
* up vmware plugin to v1.0.0
* Bump packer-plugin-azure to latest
* Update tencentcloud plugin
* Update packer-plugin-oneandone
Co-authored-by: Adrien Delorme <azr@users.noreply.github.com>
Since the build.sh script runs with `set -e` (exit _immediately_ in case
of error), we cannot first call the `which` command and, on a susequent
line, check its exit status with $?, it would be too late. Instead, we
idiomatically check on the same line of the invocation of `which`.
From the confusing:
$ make bin
==> Checking for necessary tools...
make: *** [bin] Error 1
To the informative:
$ make bin
==> Checking for necessary tools...
realpath is not on the path. Exiting...
make: *** [bin] Error 1
* fix builds on linux
* Build: Move to CGO_ENABLED=0 (#9057)
After further investigation on cross-compiling Go bins on Linux. I found
that statically linking against GCC (for libc) failed to build for ARM
and introduced a possible licensing issue as our bins would essentially
be bundling libc into the bin. Diving further into cross compiling on Linux
I found that the defacto solution is to compile with CGO disabled - this
was also found to be the case for other HashiCorp products.
Disabling CGO has the limitation of not allowing the use of any pkg that
calls out to C (net, os), but in looking into the Packer code base and
the relevant Go code base it appears that the latest versions of Go have
pure Go implementations of the said packages so I believe we are good to
go. I should also point out that CGO is disabled by default when cross
compiling via `go build`. However, the GOX tool will enable it if it is
not explicitly disabled.
Below are three test cases executed to validate the compile bins work as
expected.
Build results after change
```
⇶ make bin
WARN: 'make bin' is for debug / test builds only. Use 'make release' for
release builds.
==> Checking for necessary tools...
==> Entering Packer source dir...
==> Ensuring output directories are present...
==> Removing old builds...
==> Building...
Number of parallel builds: 7
--> windows/amd64: github.com/hashicorp/packer
--> linux/arm64: github.com/hashicorp/packer
--> linux/386: github.com/hashicorp/packer
--> linux/arm: github.com/hashicorp/packer
--> darwin/amd64: github.com/hashicorp/packer
--> windows/386: github.com/hashicorp/packer
--> linux/amd64: github.com/hashicorp/packer
--> darwin/386: github.com/hashicorp/packer
==> Copying binaries for this platform...
'./pkg/linux_amd64/packer' -> 'bin/packer'
'./pkg/linux_amd64/packer' -> '/home/wilken/Development/go/bin/packer'
==> Results:
total 111M
-rwxr-xr-x 1 wilken wilken 111M Apr 13 12:29 packer
```
Packer executed on ARM based machine
```
ubuntu@ip-172-31-10-18:~$ ./packer version
Packer v1.5.6-dev (314ac5b65+CHANGES
ubuntu@ip-172-31-10-18:~$ uname -a
Linux ip-172-31-10-18 4.15.0-1054-aws #56-Ubuntu SMP Thu Nov 7 16:18:50 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux
ubuntu@ip-172-31-10-18:~$ ./packer build build.json
null: output will be in this color.
==> null: Running local shell script: /tmp/packer-shell170248556
null: UUID from Packer: 79cc8532-6114-925d-2a79-33ef6ce281cd
Build 'null' finished.
==> Builds finished. The artifacts of successful builds are:
--> null: Did not export anything. This is the null builder
```
Custom Docker image with updated bin
```
⇶ docker run packertest:latest version
Packer v1.5.6-dev (314ac5b65+CHANGES)
⇶ docker run packertest:latest build build.json
null: output will be in this color.
==> null: Running local shell script: /tmp/packer-shell065599452
null: UUID from Packer: 852f0604-2be4-9e16-99af-6d7df972ac2e
Build 'null' finished.
==> Builds finished. The artifacts of successful builds are:
--> null: Did not export anything. This is the null builder
```
Windows AMI
```
[...]
==> amazon-ebs: Launching a source AWS instance...
==> amazon-ebs: Adding tags to source instance
amazon-ebs: Adding tag: "Name": "Packer Builder"
amazon-ebs: Instance ID: i-04387545cf3e2acd3
==> amazon-ebs: Waiting for instance (i-04387545cf3e2acd3) to become ready...
==> amazon-ebs: Skipping waiting for password since WinRM password set...
==> amazon-ebs: Using winrm communicator to connect: 18.206.100.104
==> amazon-ebs: Waiting for WinRM to become available...
amazon-ebs: WinRM connected.
==> amazon-ebs: Connected to WinRM!
==> amazon-ebs: Uploading packertest => c:/Windows/Temp
==> amazon-ebs: Provisioning with Powershell...
==> amazon-ebs: Provisioning with powershell script: /tmp/powershell-provisioner173180945
amazon-ebs: Packer v1.5.6-dev (314ac5b65+CHANGES)
amazon-ebs: null: output will be in this color.
amazon-ebs:
```
Co-authored-by: Wilken Rivera <dev@wilkenrivera.com>
* new-from-rev option is showing inconsistent results on circle and
locally. This change moves to a custom command `script/lint.sh` that gets a list of added
go files and pipes them to golangci-lint for testing.
* Add a git fetch as a step before retrieving merge-base changes to fix
the issue described at https://discuss.circleci.com/t/checkout-script-adds-commits-to-master-from-circle-branch/14194/2
* Moved source code out of GOPATH to ensure go mod support and reduce
the risk of having golangci-lint trying to scan all of the files within
GOPATH. This was an issue in the past, in changing it I found less OOM
issues on circle.
This change uses git flags to shorten the log messages to titles only, and uses the grep pattern on git to filter only commits that match merged commits, including squashed and merged commits.
