Backport of Onboard consul to use new version/VERSION file and reproducible actions into release/1.13.x#15910
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
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. Have you signed the CLA already but the status is still pending? Recheck it. |
github-team-consul-core-pr-approver
left a comment
There was a problem hiding this comment.
Auto approved Consul Bot automated PR
|
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. |
|
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. |
Backport
This PR is auto-generated from #15631 to be assessed for backporting due to the inclusion of the label backport/1.13.
WARNING automatic cherry-pick of commits failed. Commits will require human attention.
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.1and1.0.0-dev→1.0.0. Bumping the minor version (ie1.0.x→1.1.0) is only supported manually viabob 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:
.release/VERSIONfile 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).VERSIONfile in the.release/ dirproduct_versionif it is1.3.0-alpha1as1.3.0(example: whenproduct_version = 1.3.0-alpha1,base_version = 1.3.0)alpha1(exampleprerelease_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.goandbase_version.gofiles 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:
This PR also introduces a bump to the version tags for
actions/checkout,actions/setup-go, andactions/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
prepareworkflow in theci.hclconfig 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. Thepreparerunsupload-dev,security-scan,notarize,sign,verify,promote-dev-docker, andfossa-scan(depending on your team’s current needs) under the hood - no need to worry about these workflows anymore!TODO Before Merging
set-product-versionbranch frombuild.ymlworkflow dispatch listset-product-versionbranch fromci.hclallowlistOverview of commits