Backport of Onboard consul to use new version/VERSION file and reproducible actions into release/1.12.x

[hc-github-team-consul-core]

Backport

This PR is auto-generated from #15631 to be assessed for backporting due to the inclusion of the label backport/1.12.

WARNING automatic cherry-pick of commits failed. Commits will require human attention.

merge conflict error: POST https://api.github.com/repos/hashicorp/consul/merges: 409 Merge conflict []

The below text is copied from the body of the original PR.

---

PR Description

This PR 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. This PR also introduces automatic version patch bumping via the bump-version {todo: enter link when merged} workflow.

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-patch” in the ci.hcl file in this PR.

What this small action does:

• Allows for the static version string from the .release/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 .release/ 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.

In other words, the action grabs the version from the version file at the beginning of the build, then passes those versions (along with metadata, where necessary) to the new version bump automation CRT workflow at the end of the release pipeline to bump the product’s version. One thing to note is that the version.go and base_version.go files are used for local development and will be now overwritten by the ld-flags with the actual version that are being called in the go builds.

This PR also introduces actions-go-build, an action that dynamically takes care of building and packaging go binaries. Through this action, you can define the go build, assert that it’s reproducible (optional*) and then use the artifacts in the workflow. (Once the build action run is finished, you can check out it the builds are reproducible by scrolling down on the summary page, example)

*NOTE: if assert is enabled, this could potentially create some disruptions in workflows as the action tries to verify two builds (primary build and ui builds) are the same (size, shasums) as ui builds might have non-deterministic compilation.

Passing tests ✔️ Check out these examples:

• https://github.com/hashicorp/consul-enterprise/actions/runs/3623272718

This PR also introduces a bump to the version tags for actions/checkout, actions/setup-go, and actions/upload-artifact (setup-go version tag update was required by the introduction of actions-go-build)-- however, if the Packer team feels like these should be isolated in their own PRs for easier/broader visibility, super happy to raise separate PRs!

Finally, as a part of this effort to onboard new CRT tooling, we have implemented the new prepare workflow in the ci.hcl config file. This workflow simply wraps all workflows in the pre-stable channel in one workflow, to make your ci.hcl config file more readable for your team. The prepare runs upload-dev, security-scan, notarize, sign, verify, promote-dev-docker, and fossa-scan (depending on your team’s current needs) under the hood - no need to worry about these workflows anymore!

TODO Before Merging

• Update version/VERSION to latest version
• Remove set-product-version branch from build.yml workflow dispatch list
• Remove set-product-version branch from ci.hcl allowlist

---

Overview of commits

• a98fa8d - 8152ecf - e9f33a1 - be97ac9 - 83dbb23 - 8c98f5f - 78ee14f - 5e23cd7 - 607b309 - 1bb4b45 - b310777 - 5aaf6e4 - 0546c6e - 2ff351a - 4c097b8 - 9bfc23d - 473f281 - 6ef395d - c977e4c - 5caad41 - c3b96fb - e9d0646 - 71b7e46 - 6e5129c - fc4a05f - e14b645 - 046afb2 - 50984a9 - 92e34a4 - c551766 - bbd1cb0 - 76a14dc

[hashicorp-cla]

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes

---

temp seems not to be a GitHub user.
You need a GitHub account to be able to sign the CLA. If you already have a GitHub account, please add the email address used for this commit to your account.

_{Have you signed the CLA already but the status is still pending? Recheck it.}

[github-team-consul-core-pr-approver]

Auto approved Consul Bot automated PR

[github-actions]

This pull request has been automatically flagged for inactivity because it has not been acted upon in the last 60 days. It will be closed if no new activity occurs in the next 30 days. Please feel free to re-open to resurrect the change if you feel this has happened by mistake. Thank you for your contributions.

[github-actions]

Closing due to inactivity. If you feel this was a mistake or you wish to re-open at any time in the future, please leave a comment and it will be re-surfaced for the maintainers to review.