Bump hashicorp/actions-docker-build from 1 to 2

[dependabot]

Bumps hashicorp/actions-docker-build from 1 to 2.

Release notes

Sourced from hashicorp/actions-docker-build's releases.

v2

Update all actions to node20.

v1.6.1

Now that Redhat supports multi-arch images, we suggest product teams do UBI builds in one step (tagging both for dockerhub and quay.io).

This release removes the current exclusive or between dockerhub/AWS tags and quay.io tags from the variable check script.

v1.6.0

Added Windows Docker build support

v1.5.2

hashicorp/actions-docker-build#59 - adds optional REVISION input

v1.5.1

Adds hashicorp/actions-docker-build#46

v1.3.5

• [RELENG-74] Update actions-docker-build to support including multiple binaries in a single docker image

v1.3.4

• add context to version label validation by @​alvin-huang in hashicorp/actions-docker-build#26

v1.3.3

[RELENG-20] validate version label is set in built image by @​alvin-huang in hashicorp/actions-docker-build#25

v1.3.1

Handles enterprise version correctly: if there's already version metadata supplied, it is used as-is rather than appending another +ent to the end.

v1.2.1

• Fix for REPO_NAME not being set when calling the workflow from a schedule.

v1.2.0

• Fixing issue with docker buildx targeting arm cpus from amd64 host
• Add capability to run docker images smoke test in CI

v1.1

You can now add a parameter dev_tags which is very similar to the tags parameter that already exists.

If this parameter is set, these additional tags are also created when building the Docker images.

Downstream processes treat "dev tags" specially: they are pushed automatically when they reach the "stable" channel, meaning all tests have passed and they are signed and scanned. This allows continuous updating of public images on DockerHub for development purposes. For production purposes, the other tags are the ones to use. Those ones are only pushed when an official product release is made.

Internal: See RELTOOL-52 for full details of this and related changes.

v1.0.1

Fixing AUTO_TAG to include VERSION and match TARBALL_NAME.

Changelog

Sourced from hashicorp/actions-docker-build's changelog.

Changelog - Docker Build Action

v1.3.1

• Resolve issue where the internal auto tag was invalid with enterprise versions.

v1.3.0

No entries.

v1.2.2

• Better handling of enterprise versions and complex version strings, e.g. 1.2.3+ent-fips.XYZ now interpreted correctly.

v1.2.1

• Fix for REPO_NAME not being set when calling the workflow from a schedule.`

v1.2.0

• Fixing issue with docker buildx targeting arm cpus from amd64 host
• Add capability to run docker images smoke test in CI

v1.1.0

• Fixed: When setting workdir: that directory is used for downloading the binary artifact. This fixes the issue where it was possible to download the artifact to a place outside of the docker build context (i.e. where it was not accessible).

• Changed: No longer performs checkout, expects caller to have already checked out. This fixes an issue where mutations to the repository are needed prior to building. Note that this mutation is probably an anti-pattern, but it's not this action's responsibility to force users' hands one way or the other over this.

• Changed: Added some simple tests, see .github/workflows/test.yml.

v1.0.1

• Changed: The automatic tags now include the version, matching the tarball name.

v1.0.0

Initial version.

Commits

• 11d43ef Merge pull request #77 from hashicorp/ashley/update-artifact-actions
• b7ebaa1 remove overwrite:yes and fix env_var name
• 3802549 create uniquely named artifact, store them all (duplicate is duplicate and ma...
• 42c7ab6 Merge pull request #78 from hashicorp/update-codeowners
• 527ce4e Update CODEOWNERS for SMRE
• 196f312 Update Artifact Actions to use > v4.0.0
• 1b87176 Add windows to example (#76)
• 76d2fc9 Merge pull request #73 from hashicorp/curtbushko/support-docker-build-args
• 8ed20c5 regenerate github.env
• f79ab0c missing something in the action
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[DanStough]

Handles in #1930

[dependabot]

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version. You can also ignore all major, minor, or patch releases for a dependency by adding an ignore condition with the desired update_types to your config file.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.