tools/release/scripts/generate-range-notes.mjs (3)

178-205: detectReleaseType duplicates/drifts from release-policy.cjs.

The release impact for feat/fix/perf/revert/refactor is hardcoded here rather than derived from policyByType.get(type).release. This diverges from the single source of truth: e.g., feat is implicitly minor here but has no release field in the policy; fix/perf are hardcoded patch with no policy entry; and if someone later sets release: "minor" for, say, perf in release-policy.cjs, the semantic-release flow picks it up but this range-notes generator does not — producing inconsistent predicted versions between stable and RC/nightly flows.

Consider deriving directly from the policy, with feat as the only special-case (conventionalcommits default → minor) when no explicit release is configured:

♻️ Proposed refactor

 function detectReleaseType(conventional, body) {
   if (!conventional) {
     return "none";
   }

   if (conventional.breaking || findBreakingNotes(body, conventional.subject).length > 0) {
     return "major";
   }

-  if (conventional.type === "feat") {
-    return "minor";
-  }
-
-  if (conventional.type === "fix" || conventional.type === "perf" || conventional.type === "revert") {
-    return "patch";
-  }
-
-  if (conventional.type === "refactor") {
-    return "patch";
-  }
-
   const policy = policyByType.get(conventional.type);
-  if (policy?.release === false) {
-    return "none";
-  }
-
-  return "none";
+  if (policy && typeof policy.release === "string") {
+    return policy.release;
+  }
+  if (policy?.release === false) {
+    return "none";
+  }
+  // conventionalcommits defaults when not overridden by policy
+  if (conventional.type === "feat") return "minor";
+  if (conventional.type === "fix" || conventional.type === "perf") return "patch";
+  return "none";
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tools/release/scripts/generate-range-notes.mjs` around lines 178 - 205,
detectReleaseType currently hardcodes release mapping for conventional.type
(feat/fix/perf/revert/refactor) instead of consulting the single source of truth
in policyByType (from release-policy.cjs), causing drift; update
detectReleaseType to derive the release kind from
policyByType.get(conventional.type)?.release when conventional is present,
treating the special case that if no explicit policy release exists and
conventional.type === "feat" then return "minor", and still return "major" when
conventional.breaking or findBreakingNotes(body, conventional.subject).length >
0; ensure the final fallback returns "none" only when policy explicitly disables
release or no rule applies (use symbols detectReleaseType, policyByType,
conventional.type, findBreakingNotes to locate changes).

---

207-216: Defensive: guard against unknown release types in maxReleaseType.

If next is ever a value not in rank (e.g., future addition like "prerelease"), rank.get(next) is undefined and undefined > number is false, so the new value is silently dropped. A cheap guard + thrown error would catch misuse immediately. Optional.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tools/release/scripts/generate-range-notes.mjs` around lines 207 - 216, The
maxReleaseType function should defensively validate release types from the rank
map before comparing; update maxReleaseType to check rank.has(next) and
rank.has(current) (or check rank.get(...) !== undefined) and throw a clear
TypeError including the offending value(s) if an unknown release type is
encountered, so unknown types like "prerelease" are caught instead of silently
dropped.

---

119-141: Minor: redundant findBreakingNotes invocation per commit.

findBreakingNotes(body, subject) runs during commit construction (line 132), then runs again inside detectReleaseType (line 183) on every commit. For large ranges this doubles the body-line scanning. Consider computing the notes once and passing them into detectReleaseType, or checking breakingNotes.length already attached to the commit. Low impact; nit.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tools/release/scripts/generate-range-notes.mjs` around lines 119 - 141, In
parseCommits, avoid calling findBreakingNotes twice by computing const
breakingNotes = findBreakingNotes(body, subject) once when building each commit
object and attaching it to the commit, then update the call to detectReleaseType
to accept or use that precomputed breakingNotes (e.g.,
detectReleaseType(conventional, body, breakingNotes) or have detectReleaseType
check commit.breakingNotes where it's invoked) and update any other callers of
detectReleaseType accordingly so the heavy body scan is not repeated.

.github/workflows/release-candidate.yml (1)

97-113: Minor: redundant always() and unconditional Discord post.

• if: ${{ always() && needs.generate-notes.result == 'success' }} — the always() is redundant; needs.generate-notes.result == 'success' already implies both upstream jobs completed (since generate-notes depends on resolve_ref).
• The job fires even when needs.generate-notes.outputs.released == 'true' is false (no releasable commits in range). For manual RC dispatch this is likely intentional (operator asked for the broadcast), but worth confirming — otherwise add && needs.generate-notes.outputs.released == 'true' to suppress empty RC pings.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/release-candidate.yml around lines 97 - 113, Update the
notify-discord job condition: remove the redundant always() wrapper and set if
to require successful generate-notes (use if: ${{ needs.generate-notes.result ==
'success' }}), and — unless you intentionally want manual RC dispatches to
always post — add the released guard to suppress empty pings by changing the
condition to if: ${{ needs.generate-notes.result == 'success' &&
needs.generate-notes.outputs.released == 'true' }}; reference the notify-discord
job and its if line in the workflow to make this change.

.github/actions/compute-release-notes/action.yml (1)

72-113: LGTM — small note on output size.

Extraction fields (compareUrl, nextVersion, releaseType, released, toSha) match the JSON payload in tools/release/scripts/generate-range-notes.mjs, and the random EOF_<hex> delimiter guards against content collisions in release_notes. Just be aware that release_notes propagated as a composite-action output + reusable-workflow output can approach the 1 MB step output limit for large ranges (e.g., a stale base tag on a very active develop). The artifact upload at lines 131–139 mitigates loss, so this is informational.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/actions/compute-release-notes/action.yml around lines 72 - 113, The
step "Extract Range Outputs" can emit a very large release_notes value and risk
hitting the 1 MB GitHub step output limit; update the logic handling
release_notes (the release_notes<<${release_notes_delim} block that reads
tools/release/range-release-notes.md) to guard against oversized output by
either truncating or compressing the content before appending to GITHUB_OUTPUT
(or alternatively always persist the full file as an artifact and only emit a
small summary to GITHUB_OUTPUT), and ensure the changes reference the same
symbols: the release_notes variable, tools/release/range-release-notes.md, and
the "Generate Range Notes" / "Extract Range Outputs" steps so the output remains
safe for composite-action and reusable-workflow usage.

.github/workflows/notify-discord-release-notes.yml (1)

136-145: Constrain mention parsing for Discord notifications.

CONTENT can include configurable mention_text; add allowed_mentions so a bad variable value does not accidentally ping @everyone/@here while still allowing role/user mentions.

🔒 Suggested payload guard

               {
                 content: $content,
+                allowed_mentions: {
+                  parse: ["users", "roles"]
+                },
                 embeds: [
                   {
                     title: "Build Details",

Please verify this matches the current Discord webhook allowed_mentions behavior if @here/@everyone pings are intentionally supported.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/notify-discord-release-notes.yml around lines 136 - 145,
The Discord webhook payload currently builds an object with content and embeds
(title "Build Details", description $description) but lacks an allowed_mentions
field; update the webhook payload object to include an allowed_mentions property
that explicitly restricts parsing to only "users" and "roles" (or an explicit
list) so user/role pings remain allowed but `@here`/`@everyone` cannot be
triggered by a bad mention_text value; reference the payload object where
content/$content and embeds (title "Build Details", description $description)
are defined and add allowed_mentions accordingly, and verify the final behavior
matches Discord's webhook semantics if `@here`/`@everyone` support is
intentional.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

.github/workflows/publish-nightly.yml (1)

46-63: ⚠️ Potential issue | 🟡 Minor

Validate base_tag before using it as the fallback range start.

The previous nightly SHA is now ancestry-checked, but when it is absent or unusable, from_ref remains base_tag. If that stable tag is not on develop history, the nightly range can still be misleading.

🛠️ Suggested fallback hardening

           base_tag="$(git describe --tags --abbrev=0 --match 'v*' origin/main)"
           from_ref="$base_tag"
+          if ! git merge-base --is-ancestor "$base_tag" HEAD; then
+            base_merge="$(git merge-base "$base_tag" HEAD || true)"
+            if [ -z "$base_merge" ]; then
+              echo "::error::Stable base ${base_tag} is unrelated to HEAD"
+              exit 1
+            fi
+            echo "::warning::Stable base ${base_tag} is not an ancestor of HEAD; using merge-base ${base_merge}"
+            from_ref="$base_merge"
+          fi
           previous_nightly_sha=""

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/publish-nightly.yml around lines 46 - 63, Validate that
base_tag is a reachable ancestor of the current branch before using it as the
fallback for from_ref: check that base_tag exists (git rev-parse --verify) and
is an ancestor of HEAD (git merge-base --is-ancestor); if either check fails,
emit a warning and choose a safer fallback (for example use the repository root
commit or leave from_ref unset/use HEAD's first parent commit) instead of
blindly using base_tag. Update the logic around base_tag, from_ref, and
previous_nightly_sha to perform these checks and set from_ref only when base_tag
is verified as a valid ancestor; keep the existing warnings for unusable
baselines and ensure process uses the verified symbol names base_tag, from_ref,
and previous_nightly_sha.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes