Summary

This repository is consumed as a GitHub composite action, but it has no version tags, so the documented usage pins @master. Consumers cannot pin an immutable version, and there is no supported way to cut a release or publish release notes. Semgrep's github-actions-mutable-action-tag rule applies, since a branch reference is mutable by definition and can be repointed after consumers have already pinned to it. We want a manually triggered workflow that bumps the version (patch/minor/major), creates a signed tag, and publishes a GitHub Release with generated notes, plus a dry-run option to preview a release before it happens. A v1.0.0 tag will be created as the starting point.

Motivation

Who is the affected end user?

Maintainers of this repository who cut releases, and the MongoDB driver teams that consume its GitHub Action.

How does this affect the end user?

Consumers are exposed to every change to this repository the moment it merges, with no way to pin a known-good version and no release notes to tell them what changed. Maintainers have no supported way to produce a versioned, documented release.

How likely is it that this problem or use case will occur?

Main path. It affects every consumer of the action and every change to this repository.

If the problem does occur, what are the consequences and how severe are they?

A change in the repo can currently break consumer CI with no pinned version to fall back to, and no notes to identify what changed. The mutable reference is also a supply-chain integrity concern: consumers execute whatever the branch tip happens to be when their workflow runs, and anyone able to move that ref can change what they execute without their knowledge. That is a standing static-analysis finding for every consumer that pins @master, under the same semgrep rule DRIVERS-3601 cites. Immutable version tags let those consumers resolve the finding, and this ticket deliberately does not introduce floating major-version tags, so the pattern is not reintroduced in a new form.

Is this issue urgent?

Not blocking, but it is a prerequisite for driver teams to move off @master pins and clear the associated semgrep finding.

Is this ticket required by a downstream team?

No specific downstream ask. It benefits every driver team that consumes the action.

Is this ticket only for tests?

No, functional change.

Acceptance Criteria

• A manually triggered workflow accepts a version-bump type (patch/minor/major) and a dry-run option.
• It reads the highest existing version tag, computes the next version, then creates that tag and publishes a GitHub Release with generated notes.
• The release tag is a signed annotated tag, produced through the shared MongoDB signing tooling rather than created implicitly by the release step.
• Dry-run mode reports the next version, previews the notes, and exercises the signing path without pushing a tag or publishing a release.
• A real release runs only on the default branch.
• A v1.0.0 tag and release exist as the starting point, and the documented action usage explains how to pin a released version.