[johnmtll]

Description

Summary of Changes

Follows the releasing guidelines for backporting. This backports release scripts/workflows from main into 6.x (based off of 6.21.0). Also backports CI tooling/scripts so that when the backport code lands, CI can show as passing.

Notes for Reviewers

What is the motivation for this change?

For bug fixes

Current (incorrect) behavior:

Expected behavior:

How to reproduce:

Affected versions:

Release Highlight

Release notes highlight

Double check the following

• Lint is passing (npm run check:lint)
• Self-review completed using the steps outlined here
• PR title follows the correct format: type(NODE-xxxx)[!]: description
  • Example: feat(NODE-1234)!: rewriting everything in coffeescript
• Changes are covered by tests
• New TODOs have a related JIRA ticket

[evergreen-ci-prod]

There is an existing patch(es) for this commit SHA:

• Evergreen patch with PR

Please note that the status that is posted is not in the context of this PR but rather the (latest) existing patch and that may affect some tests that may depend on the particular PR. If your tests do not rely on any PR-specific values (like base or head branch name) then your tests will report the same status. If you would like a patch to run in the context of this PR and abort the other(s), comment 'evergreen retry'.

[semgrep-code-mongodb]

Semgrep found 7 github-actions-mutable-action-tag findings:

• .github/workflows/release.yml
  • L38 - Triage
  • L46 - Triage
  • L51 - Triage
  • L67 - Triage
  • L73 - Triage
  • L85 - Triage
  • L99 - Triage

🟡 Medium severity issue identified in your code:

GitHub Actions step uses a mutable tag or branch reference. Tags and branch names can be silently repointed by the action owner, enabling supply-chain attacks — as seen in the trivy-action and kics-github-action compromises. Pin the reference to a full 40-character commit SHA instead, e.g. uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608.

🛟 Help? Slack #semgrep-help or go/semgrep-help.

Resolution Options:

• Fix the code
• Reply /fp $reason (if security gap doesn’t exist)
• Reply /ar $reason (if gap is valid but intentional; add mitigations/monitoring)
• Reply /other $reason (e.g., test-only)

[PavelSafronov]

Looks good!