* start using `go:generate packer-sdc struct-markdown`
* Update Makefile
remove @go install ./cmd/struct-markdown
* run go generate for struct-markdown
* use //go:generate packer-sdc mapstructure-to-hcl2
* run go generate for mapstructure-to-hcl2
* remove struct-markdown and mapstructure-to-hcl2
* vendor vendors
Modify makefile to call generate code properly, setting project root.
'make generate' now avoids deleting website code generated in the packer plugin sdk.
For now it will be maintainers' responsibility to regenerate this docs code from the
packer plugin sdk every release, and commit it to these folders manually.
remove boot command generator code
* 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.
* golangci-lint: Update --new-from-rev option to check only code added in the latest commit
Co-authored-by: Adrien Delorme <azr@users.noreply.github.com>
While `golangci-lint run` is the same as `golangci-lint run ./...` running it without a
path seems to throw warning messages related to its cache, which is confusing.
This change sets an explicit path for golangci-lint when calling `make lint` or `make ci-lint`.
* Add golangci-lint as linting tool
* Disable failing staticchecks to start; GitHub issue to handle coming soon
* Run `goimports -w` to repair all source files that have improperly
formatted imports
* makefile: Add ci-lint target to run on travis
This change adds a new make target for running golangci-lint on newly
added Go files only. This target is expected to run during Packer ci builds.
* .github/contributing: Add code linting instructions
* travis: Update job configuration to run parallel builds
Adrien Delorme
Wilken Rivera
Megan Marsh
Wilken Rivera
Ivo van Geel
Jeff Escalante
Sylvia Moss
Adrien Delorme