* [builder/azure-arm] Use VM/build location for image locationThe builder was using the location of the containing resource group asthe image location, but the API call can only create images in the samelocation as the source VM that is being captured.
Adds `enable_secure_boot`, `enable_vtpm` and `enable_integrity_monitoring`
config options to enable building of custom Shielded GCP Compute images.
Feedback on this is more than welcome as this is my first attempt in
contributing to anything Packer related.
Packer is great for us to build custom images on top of GCP but we would
like to enhance that to support Shielded VM images. This will allow us
to have more secure and trusted images which our team(s) will be using.
* 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>
* mapstructure-to-hcl2: when we see a map generate an attribute spec and not a block spec
this will alow to do
tags = {
key = "value"
}
instead of
tags {
key = "value"
}
This will also enable using variables directly for those tags
* generate code
* update tests
* 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.