ci: block npm releases with open blockers

[dkropachev]

Summary

• add a shared fail-closed check for open release-blocker issues
• check at the start of the publish job and again immediately before npm publish
• grant the publish job read-only issue access
• preserve publish=false dry runs

Scope

This prevents npm publication when a blocker is open. A release.published workflow starts after the tag and GitHub Release already exist, so the canonical pre-tag redesign remains tracked in #544.

Validation

• actionlint 1.7.12, excluding two pre-existing local composite-action metadata diagnostics
• workflow YAML parse
• shell syntax check
• blocked-repository path
• clear-repository path
• API-error fail-closed path
• git diff check

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: QUIET

Plan: Advanced

Run ID: 6209c2d2-9a7a-4732-a361-3a6f28522028

📥 Commits

Reviewing files that changed from the base of the PR and between 917ddcb and 423477a.

📒 Files selected for processing (2)

• .github/scripts/check-release-blockers.sh
• .github/workflows/release.yml

Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review.

---

📝 Walkthrough

Walkthrough

The release workflow now checks for open release-blocker issues before publishing and after the dry-run publish. The shared script queries GitHub through gh, reports the first blocker, and exits with status 1 when a blocker exists. The publish job now has issues: read permission.

Sequence Diagram(s)

sequenceDiagram
  participant ReleaseWorkflow
  participant BlockerScript
  participant GitHubIssues
  participant PackagePublish
  ReleaseWorkflow->>BlockerScript: Check before publishing
  BlockerScript->>GitHubIssues: Query open release-blocker issues
  ReleaseWorkflow->>PackagePublish: Run dry-run publish
  ReleaseWorkflow->>BlockerScript: Recheck blockers
  BlockerScript->>GitHubIssues: Query open release-blocker issues
  ReleaseWorkflow->>PackagePublish: Continue publishing when clear

Loading

Suggested reviewers: adespawn

Merge Risk: ⚪ Minimal · up to 42347

The release workflow now blocks npm publication when release-blocker issues are open and rechecks after the dry run. No concrete merge-blocking risk remains evidenced, so this change is mergeable.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 1…
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly identifies the main change: blocking npm releases when open release-blocker issues exist.
Description check	✅ Passed	The description clearly documents the change, scope, workflow behavior, and validation performed. It omits the repository checklist, but the core required information is present.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[qodo-scylladb]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 🔗 Cross-repo conflicts (1) 📜 Skill insights (0)

1. Dashboard shows an unpublished version 🔗 Cross-repo conflict ≡ Correctness

Description

release.yml invokes check-release-blockers.sh only inside the publish job, while the workflow
starts from an already-published GitHub release event. When an open blocker makes that check exit,
Drivers-Dashboard still selects the non-draft release as the latest Node.js driver version,
publication date, and support input even though npm publication never occurs.

Code

.github/workflows/release.yml[R147-150]

+        if: github.event_name == 'release' || inputs.publish
+        env:
+          GH_TOKEN: ${{ github.token }}
+        run: bash .github/scripts/check-release-blockers.sh

Relevance

●● Moderate

Valid architectural concern, but PR explicitly scopes pre-tag redesign separately; historical
release work preserves published-event triggering.

PR-#363
PR-#464

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The PR workflow is triggered only after a release is published, and the new check then exits before
the npm publish command when a blocker exists. Drivers-Dashboard maps this repository with
prereleases enabled, accepts every non-draft GitHub Release, chooses the first one as latest, and
uses its version and date for dashboard status without checking npm availability.

.github/workflows/release.yml[5-7]
.github/workflows/release.yml[146-150]
.github/scripts/check-release-blockers.sh[13-15]
External repo: scylladb/Drivers-Dashboard, script.js [187-192]
External repo: scylladb/Drivers-Dashboard, script.js [673-699]
External repo: scylladb/Drivers-Dashboard, script.js [763-780]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The blocker check runs after the GitHub Release becomes public, so a blocked npm release remains visible to Drivers-Dashboard as the latest driver release.

## Fix Focus Areas
- .github/workflows/release.yml[5-7]
- .github/workflows/release.yml[146-150]
- .github/scripts/check-release-blockers.sh[13-15]

## Recommended Fix
Run the blocker check in the process that creates or publishes the GitHub Release and require it to succeed before making the release non-draft. If the current post-publication trigger must remain, convert or remove the blocked GitHub Release before failing so release consumers cannot select it.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context sources

✅ Compliance rules (platform): 5 rules

✅ Cross-repo context — repo relationships

  Explored: repo: scylladb/Drivers-Dashboard (sha: 8a5c2cb8)

Review mode: ⚖️ Balanced: This changes release workflow behavior and adds fail-closed GitHub API gating around npm publication, so it warrants a careful single-pass review.

Tip of the day

💡 Did you know, you can turn these tips off under Display preferences

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-scylladb]

1. Dashboard shows an unpublished version 🔗 Cross-repo conflict ≡ Correctness

release.yml invokes check-release-blockers.sh only inside the publish job, while the workflow
starts from an already-published GitHub release event. When an open blocker makes that check exit,
Drivers-Dashboard still selects the non-draft release as the latest Node.js driver version,
publication date, and support input even though npm publication never occurs.

Agent Prompt

## Issue description
The blocker check runs after the GitHub Release becomes public, so a blocked npm release remains visible to Drivers-Dashboard as the latest driver release.

## Fix Focus Areas
- .github/workflows/release.yml[5-7]
- .github/workflows/release.yml[146-150]
- .github/scripts/check-release-blockers.sh[13-15]

## Recommended Fix
Run the blocker check in the process that creates or publishes the GitHub Release and require it to succeed before making the release non-draft. If the current post-publication trigger must remain, convert or remove the blocked GitHub Release before failing so release consumers cannot select it.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools