build(deps): bump houseabsolute/actions-rust-release from 0.0.9 to 1.0.1

[dependabot]

Bumps houseabsolute/actions-rust-release from 0.0.9 to 1.0.1.

Release notes

Sourced from houseabsolute/actions-rust-release's releases.

v1.0.1

• Documentation updates.

v1.0.0

: Creating the GitHub release has moved out of this action and into a new houseabsolute/actions-rust-release/publish action. This action now only packages your executable and uploads it as a workflow artifact.

This exists because almost everyone calls this action from inside a build matrix. When the same action both packaged and released, a matrix leg that finished early would publish its archive while other legs were still building - or failing - so a release missing one platform's executable could go public. Every leg of the matrix also raced to create the same release.

To upgrade, drop the release-specific inputs from your existing invocation and add a job which runs after all of your build jobs:

publish:
  name: Publish GitHub release
  needs: package
  runs-on: ubuntu-24.04
  permissions:
    actions: read # The publish action lists this run's artifacts.
    contents: write # Creating the release writes to this repository.
  steps:
    - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
      with:
        persist-credentials: false
    - uses: houseabsolute/actions-rust-release/publish@867cc107fb205972460c7905075c476852cd76f9 # v1.0.0
      with:
        executable-name: my-project

The tag-matching and release inputs now belong to the publish action. The packaging action no longer accepts them. See the migration guide for the details, including what happened to every v0 input.

• The publish action takes a new artifact-regex input. It asks the GitHub API which artifacts belong to the current workflow run, and only downloads and releases the ones whose names match. The default, \A<executable-name>.*\.(tar\.[a-z]+|zip)\Z, matches the archives created by the packaging action. This keeps unrelated artifacts, like coverage reports or logs, out of your releases. Note that the job calling publish needs the actions: read permission in order to list the run's artifacts.
• The release-tag-prefix input is replaced by release-tag-regex, which is a lot more flexible - it allows things like releasing on every tag, or only on tags without a pre-release suffix. Implemented by @​s3rius (Pavel Kirilin). GH #16. The default is ^v?\d+\.\d+\.\d+(-[0-9A-Za-z.-]+)?(\+[0-9A-Za-z.-]+)?$, which matches a semantic version with an optional leading v. This is narrower than the old default, which released on any tag starting with v. If you tag releases as something other than a version - nightly, or a date - you will need to set this input to keep releasing on those tags.

... (truncated)

Changelog

Sourced from houseabsolute/actions-rust-release's changelog.

1.0.1 - 2026-08-23

• Documentation updates.

1.0.0 - 2026-08-23

• Breaking change: Creating the GitHub release has moved out of this action and into a new houseabsolute/actions-rust-release/publish action. This action now only packages your executable and uploads it as a workflow artifact.

  This exists because almost everyone calls this action from inside a build matrix. When the same action both packaged and released, a matrix leg that finished early would publish its archive while other legs were still building - or failing - so a release missing one platform's executable could go public. Every leg of the matrix also raced to create the same release.

  To upgrade, drop the release-specific inputs from your existing invocation and add a job which runs after all of your build jobs:

  publish:
    name: Publish GitHub release
    needs: package
    runs-on: ubuntu-24.04
    permissions:
      actions: read # The publish action lists this run's artifacts.
      contents: write # Creating the release writes to this repository.
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          persist-credentials: false
      - uses: houseabsolute/actions-rust-release/publish@867cc107fb205972460c7905075c476852cd76f9 # v1.0.0
        with:
          executable-name: my-project

  The tag-matching and release inputs now belong to the publish action. The packaging action no longer accepts them. See the migration guide for the details, including what happened to every v0 input.

• The publish action takes a new artifact-regex input. It asks the GitHub API which artifacts belong to the current workflow run, and only downloads and releases the ones whose names match. The default, \A<executable-name>.*\.(tar\.[a-z]+|zip)\Z, matches the archives created by the packaging action. This keeps unrelated artifacts, like coverage reports or logs, out of your releases. Note that the job calling publish needs the actions: read permission in order to list the run's artifacts.

• The release-tag-prefix input is replaced by release-tag-regex, which is a lot more flexible - it allows things like releasing on every tag, or only on tags without a pre-release suffix. Implemented by @​s3rius (Pavel Kirilin). GH #16. The default is ^v?\d+\.\d+\.\d+(-[0-9A-Za-z.-]+)?(\+[0-9A-Za-z.-]+)?$, which matches a semantic version with an optional leading v. This is narrower than the old default, which released on any tag starting

... (truncated)

Commits

• 9e126fd Keep both action descriptions under 125 characters
• 9e2a2b3 Use a placeholder instead of a real SHA for this repo's actions in the docs
• 2576f1c Pin this repo's own actions in the docs to the v1.0.0 commit
• d481c41 Add release dates for v1.0.0
• 867cc10 Say when target-commitish actually does something
• fec80aa Keep the docs' YAML examples narrow enough not to scroll sideways
• 444e39e Say that two actions are what make immutable releases possible
• 1755bbb Audit the doc examples offline
• c6c3a00 Audit the docs' workflow examples in CI
• 00ddf3b Match the docs' matrix key names in this repo's own workflows
• 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 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)