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.
this will for example allow me to have the following alias:
alias buildmain='export T=$(mktemp -d) && ALL_XC_OS="linux darwin windows" ALL_XC_ARCH="amd64" GOLDFLAGS="-s -w" ./scripts/build.sh && cd pkg/ && for dir in *; do zip -r "$dir.zip" $dir & ; done ; wait && mv *.zip $T/. && open $T'
that build only on 'main' platforms, so that I can share binaries easily.
- encapsulated code in functions to make it more readable
- validate presence of used tools/binaries (check if they're in PATH)
- more output
- FIX: make all uname/OSTYPE output to lowercase and check only for that
- refactored method name convert_path -> convertPathOnCygwin
- gave convert_path two arguments to make it more readable (Readability over tight code? I don't know what is required)
- some variable expansion now uses braces