When building the container images for Packer (light and full), we
should only publish them in the version being built is a release, and
not a pre-release.
Changing this means that both light and full latest will always be only
a final release at any time.
The action currently fails when trying to remove the stale or waiting-reply labels from issues
that do not actually contain the labels in question. This update adds a guard clause to only run the
action on issues containing at least one of the labels.
The GHA action used for adding comments or labels to issues untrusted by TSCCR
have been replaced with an approved set of actions. The updated workflows use
actions/github-script for adding comments or labels to an issue.
Related to: https://github.com/hashicorp/security-tsccr/pull/608
Remove the check-legacy-links-format.yml workflow. These checks are now included as part of our
content conformance checks that run on PRs with documentation content changes.
Prior to v1.8.6 a change to the release pipeline was introduced to
automatically set and bump product version information. In that change
the ldflags for striping debug symbols was removed resulting in binaries
with full debug symbols. Thus resulting in larger binary deliverables.
This change adds the missing ldflags back into the build pipeline.
Results for Packer 1.8.5
```
~> unzip ~/packer_1.8.5_linux_amd64.zip
~> go tool nm -size packer| c++filt
reading packer: no symbol section
reading packer: no symbols
```
Results for Packer 1.8.6
```
~> unzip ~/packer_1.8.6_linux_amd64.zip
~> go tool nm -size packer| c++filt | tail -n 10
8d97ac0 2816 D vendor/golang.org/x/text/unicode/norm.nfcSparseValues
8df2f60 6144 D vendor/golang.org/x/text/unicode/norm.nfcValues
8f96fc8 8 D vendor/golang.org/x/text/unicode/norm.nfkcData
8d985c0 2816 D vendor/golang.org/x/text/unicode/norm.nfkcIndex
8fa40a0 48 D vendor/golang.org/x/text/unicode/norm.nfkcSparse
8f4a3c0 24 D vendor/golang.org/x/text/unicode/norm.nfkcSparseOffset
8db5c00 3580 D vendor/golang.org/x/text/unicode/norm.nfkcSparseValues
8e48d60 12032 D vendor/golang.org/x/text/unicode/norm.nfkcValues
8f96fd0 8 D vendor/golang.org/x/text/unicode/norm.recompMap
8fe5bd0 12 D vendor/golang.org/x/text/unicode/norm.recompMapOnce
```
Closes#12392
When tsscr bumped the version of the action to v6, we experienced some
failures in our nightly runs.
To make the action operable again, we pin the action to the former: v3.
This change will allow for release branches `release/<MAJOR>.<MINOR>.x`
to be built add uploaded to the CRT build tool chain, which can then be
promoted and released publicly if needed.
This change 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.
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” in the ci.hcl file in this PR.
What this small action does:
Allows for the static version string from the version/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 version 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.
