CRT Onboarding

[mdeggies]

Onboard Packer OSS to Common Release Tooling

There are a few important changes to call out in this PR:

• GitHub Actions is being used as the CI provider to build the go binary artifacts, docker image, and linux packages. This logic lives in .github/workflows/build.yml and workflow runs are available under https://github.com/hashicorp/packer/actions.
• Artifact builds will continue to run on PR's and merges to master. This behavior can be changed by updating the on: logic in the .github/workflows/build.yml file.
• The .release/ci.hcl file contains some metadata for our release service. The only part you'll likely ever need to change is the release_branches array -- when you want to release off of a new release branch, update this value to the release branch name and be sure to update the branches array in .github/workflows/build.yml to the same value. This should be set to either main, the release branch that we'll be releasing off of (once release branches are adopted), or a test branch that you are working off of if you need to validate every part of the pipeline before merging.
• The netcgo tag has been added for darwin binaries to avoid issues that customers have faced connecting over a VPN. More detail in this RFC. After this PR is merged, the next Packer release will close Packer 1.5.6+ does not use macOS system DNS resolver and cannot connect to host #9710

Things to call out in the changelog for the next release using CRT:

• The dockerfile that is used to build the packer docker image available at hashicorp/packer now lives in the root of this repo. The README that describes how to build the docker targets defined in the Dockerfile are available under ./release/docker/README.md.
• Docker images are now available for all supported architectures that the linux binaries are built for including arm, arm64, 386, and amd64
• Packer's linux package service configs and pre/post install scripts are now available under .release/linux
• Packer's linux packages are now available for all supported linux architectures including arm, arm64, 386, and amd64

Other odds and ends to note:

• All CircleCI jobs were ported over to GitHub Actions
• The acceptance tests will now run on a cron on the default branch every day at midnight. In the future, we can add slack notifications to make failures more visible to the team
• After merging and releasing, https://github.com/hashicorp/docker-hub-images can be archived
• After merging and releasing, https://github.com/hashicorp/packer-releases can be archived
• After merging and releasing, we can remove the CircleCI hooks from this project
• Shared documentation exists here that describes how to promote artifacts to staging and to production.

Still TODO:

• Add website-docker-image job secrets to GitHub Actions
• Add acceptance test secrets to GitHub Actions and change the workflow to run on either merges to master or at a scheduled time (e.g. nightly)
• Port over nightly github prereleases to GHA
• Sync with Packer team to validate built artifacts and align on naming convention for docker images pushed to DockerHub and AWS ECR

[samsalisbury]

Hi @mdeggies I only reviewed the docker parts, I hope this is helpful, let me know if I can help with addressing any of the issues or improving documentation around them, thanks :)

[nywilken]

Artifact builds will now only run on merges to the release branches or to main

Are you referring to the Artifact builds that get built from PRs? For example https://app.circleci.com/pipelines/github/hashicorp/packer/11432/workflows/f32c1dc5-9e34-4e48-b267-7d2f6e46b698/jobs/140848

[nywilken]

This is looking really good. Thank you for opening up this PR and helping with the onboarding to CRT. I left a couple of questions so far.

I'll continue reviewing and look to test the built artifacts.

[alvin-huang]

@kpenfound would you mind double checking the Linux packaging files?

[nywilken]

This looks really good to me. I left two questions.

Previously, upon a successful release the CHANGELOG would be updated to reflect the latest release version. Is that handled in the CRT? Or do we need to add the upcoming version information ourselves after a release. It is okay if we do. I'm just asking so that I can update our docs.

[nywilken]

🎉 this is going to be awesome.

[nywilken]

Do we need to update this file when upgrading to a new version of Go?

[mdeggies]

Yes! If the version of go changes that is used to build packer in CI, this will need to be updated.

[nywilken]

Note to @hc-github-team-packer we need to update this README once #11598 is complete

[nywilken]

I pushed an update to fix the issue. This may cause a conflict here that needs to be pulled in.

[mdeggies]

This is great. TY!

[nywilken]

👍

[mdeggies]

Previously, upon a successful release the CHANGELOG would be updated to reflect the latest release version. Is that handled in the CRT? Or do we need to add the upcoming version information ourselves after a release. It is okay if we do. I'm just asking so that I can update our docs.

We don't have this automated in CRT yet, but it's on our short term roadmap, so hopefully we'll be able to get to it soon. We post updates about new / changing functionality over in #feed-crt-newsletter, so feel free to hop in there to subscribe

[nywilken]

We are going to officially release next week. So we will walk through the whole process. If there are any kinks we can address them in the actual release workflow. Does that sound good to you?

If so, please feel free to merge when ready.

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.