-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add new build Action #280
Add new build Action #280
Conversation
This change adds a new build Action while keeping the current release Action intact. The intent is to incrementally gain confidence in the new Action by operating both workflows in parallel for some time. The new build Action is, in fact, not entirely new. See prior art in [Terraform Core](https://github.com/hashicorp/terraform/blob/main/.github/workflows/build.yml) and other repos. Here are a few benefits for official Terraform providers: * Matrixed Go builds * Single responsibility -- build-only, rather than build and release * ZIP archives uploaded as GitHub Actions artifacts for further processing by other Actions
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, great step forward 🚀
# We use .go-version as our source of truth for current Go | ||
# version, because "goenv" can react to it automatically. | ||
# Specify the exact Go version (e.g., 1.22.4) in .go-version | ||
# if your build requires a specific patch version of Go. | ||
# Otherwise, specify the major and minor versions (e.g., 1.22), | ||
# with a caveat that it can lead to builds using different | ||
# patch versions of Go in a workflow run. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting! I wonder if now that the Go toolchain defaults to including patch version details in the go.mod
, if we really need this static file in the future 🤔
- uses: actions/checkout@8e5e7e5ab8b370d6c329ec480221332ada57f0ab # v3.5.2 | ||
- name: Set Product version | ||
id: set-product-version | ||
uses: hashicorp/actions-set-product-version@v1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: in the future we should probably point their actions to the commit hash (also noticed they have a v2 that their example is not updated to use 😆 )
Our internal tool TSCCR doesn't support pinning/upgrading hashicorp actions for us 🙃
https://github.com/hashicorp/security-tsccr/issues/674
This change adds a new build Action while keeping the current release Action intact. The intent is to incrementally gain confidence in the new Action by operating both workflows in parallel for some time.
Any builds generated by this Action will simply be uploaded as Actions artifacts and go nowhere beyond that.
The new build Action is, in fact, not entirely new. See prior art in Terraform Core and other repos. Here are a few benefits for official Terraform providers: