feat(ci): auto-trigger make-release and docs rebuild on PR merge

.github/workflows/on_layer_docs_pr_merge.yml

@@ -0,0 +1,58 @@
+name: Auto-trigger docs rebuild on layer ARN docs PR merge
+
+# PROCESS
+#
+# This workflow watches for `publish_layer.yml`'s `update_layer_arn_docs` job PR (branch
+# `ci-layer-docs-<run_id>`) merging to `main` so it can dispatch `rebuild_latest_docs.yml`
+# automatically, leaving only the human action that requires actual review: approving the
+# ARN-doc PR.
+#
+# SECURITY NOTE
+#
+# Deliberately uses `pull_request` (not `pull_request_target`), so PRs from forks keep
+# GitHub's default read-only token and no secrets - a forked PR could never reach the
+# `gh workflow run` step even if every other condition below matched.
+#
+# `github.event.pull_request.user.login` is set by GitHub from the identity that actually
+# called the API to open the PR - it isn't spoofable via branch name, PR title, or body.
+# `ci-layer-docs-*` PRs are opened by aws-powertools/actions' `create-pr` action using the
+# default `GITHUB_TOKEN`, so `.user.login` is always `github-actions[bot]` (confirmed
+# against real PR history - this is NOT the same as `aws-powertools-bot`, which is only
+# the git commit-author identity `create-pr` sets locally via `git config`, not what
+# GitHub exposes as the PR's author).
+#
+# Combined with `head.repo.full_name == github.repository` (rejects forks explicitly)
+# and `base.ref == 'main'`, only genuine automation-opened, same-repo, main-targeted
+# PRs can reach the dispatch step.
+
+on:
+  pull_request:
+    types: [closed]
+
+permissions: {}
+
+jobs:
+  trigger-rebuild-docs:
+    if: >
+      github.event.pull_request.merged == true &&
+      github.event.pull_request.base.ref == 'main' &&
+      github.event.pull_request.head.repo.full_name == github.repository &&
+      github.event.pull_request.user.login == 'github-actions[bot]' &&
+      startsWith(github.event.pull_request.head.ref, 'ci-layer-docs-')
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+      actions: write
+    steps:
+      - name: Checkout main
+        uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
+        with:
+          ref: main
+      - name: Resolve latest published version
+        id: version
+        run: echo "version=$(cat packages/commons/package.json | jq .version -r)" >> "$GITHUB_OUTPUT"
+      - name: Dispatch Rebuild latest docs
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          VERSION: ${{ steps.version.outputs.version }}
+        run: gh workflow run rebuild_latest_docs.yml --repo ${{ github.repository }} --ref main --field latest_published_version="$VERSION"

.github/workflows/on_version_bump_pr_merge.yml

@@ -0,0 +1,49 @@
+name: Auto-trigger Make Release on version bump PR merge
+
+# PROCESS
+#
+# This workflow watches for `make-version.yml`'s version-bump PR (branch `ci-bump-<run_id>`)
+# merging to `main` so it can dispatch `make-release.yml` automatically, leaving only the
+# human actions that require actual review: approving the version PR and approving npm
+# publish.
+#
+# SECURITY NOTE
+#
+# Deliberately uses `pull_request` (not `pull_request_target`), so PRs from forks keep
+# GitHub's default read-only token and no secrets - a forked PR could never reach the
+# `gh workflow run` step even if every other condition below matched.
+#
+# `github.event.pull_request.user.login` is set by GitHub from the identity that actually
+# called the API to open the PR - it isn't spoofable via branch name, PR title, or body.
+# `ci-bump-*` PRs are opened by aws-powertools/actions' `create-pr` action using the
+# default `GITHUB_TOKEN`, so `.user.login` is always `github-actions[bot]` (confirmed
+# against real PR history - this is NOT the same as `aws-powertools-bot`, which is only
+# the git commit-author identity `create-pr` sets locally via `git config`, not what
+# GitHub exposes as the PR's author).
+#
+# Combined with `head.repo.full_name == github.repository` (rejects forks explicitly)
+# and `base.ref == 'main'`, only genuine automation-opened, same-repo, main-targeted
+# PRs can reach the dispatch step.
+
+on:
+  pull_request:
+    types: [closed]
+
+permissions: {}
+
+jobs:
+  trigger-make-release:
+    if: >
+      github.event.pull_request.merged == true &&
+      github.event.pull_request.base.ref == 'main' &&
+      github.event.pull_request.head.repo.full_name == github.repository &&
+      github.event.pull_request.user.login == 'github-actions[bot]' &&
+      startsWith(github.event.pull_request.head.ref, 'ci-bump-')
+    runs-on: ubuntu-latest
+    permissions:
+      actions: write
+    steps:
+      - name: Dispatch Make Release
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        run: gh workflow run make-release.yml --repo ${{ github.repository }} --ref main

docs/maintainers.md

@@ -228,16 +228,16 @@ Releasing a new version is a multi-step process that requires up to 3 hours to c
 
 1. **End to end tests**: Run the [e2e tests](#run-end-to-end-tests) and ensure they pass.
 2. **Version bump**: Run the `Make Version` workflow to bump the version. This will create a PR with the new version and
-a changelog. Visually inspect the diff and make sure the changelog and version are correct, then merge the PR.
-3. **Make Release**: Run the `Make Release` workflow. This will: 1/ run the unit tests again, 2/ build and publish to npmjs.com,
+a changelog. Visually inspect the diff and make sure the changelog and version are correct, then merge the PR. Merging
+this PR automatically triggers the `Make Release` workflow.
+3. **Make Release**: The `Make Release` workflow will: 1/ run the unit tests again, 2/ build and publish to npmjs.com,
 3/ build and deploy the Lambda layers to the `Beta` and `Prod` environments in all commercial Regions, 4/ run canary
 tests, 5/ deploy the Lambda layers to the `GovCloud` and `China` partitions (Gamma then Prod, both in parallel) once the
-commercial Prod deployment finishes, 6/ update the documentation with the new version once all three (commercial,
-GovCloud, China) Prod deployments are complete.
+commercial Prod deployment finishes, 6/ open a PR to update the documentation with the new layer ARNs once all three
+(commercial, GovCloud, China) Prod deployments are complete.
 4. **Review and merge docs PR**: Once the `Make Release` workflow is complete, a PR will be created to update the
-documentation with the new version. Review and merge this PR.
-5. **Update Docs**: Run the `Rebuild latest docs` workflow with the `main` branch using the package version from
-npm (i.e. `2.20.0`). This will update the documentation with the new version.
+documentation with the new version. Review and merge this PR. Merging this PR automatically triggers the
+`Rebuild latest docs` workflow, which updates the documentation with the new version.
 
 Once complete, you can start drafting the release notes to let customers know **what changed and what's in it for them (a.k.a why they should care)**. We have guidelines in the release notes section so you know what good looks like.