CI:: declare explicit permissions for stale and weekly cron workflows

[Rohan5commit]

Summary

• add explicit permissions to .github/workflows/stale.yml
• add explicit permissions to .github/workflows/cron-weekly.yml

Why

Both workflows previously relied on implicit token defaults. Declaring explicit scopes makes required access clear and keeps token privileges least-privilege:

• stale.yml: issues: write, pull-requests: write for actions/stale
• cron-weekly.yml: contents: read for repository checkout during markdown link checks

Validation

• reviewed workflow steps against required GitHub API operations
• confirmed no additional repository write scopes are needed

Summary by CodeRabbit

• Chores
  • Enhanced GitHub Actions workflow permissions to enable automated link validation and streamlined issue and pull request management.

[dosubot]

Related Documentation

Checked 0 published document(s) in 1 knowledge base(s). No updates required.

^{How did I do? Any feedback?}  

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR adds permission blocks to two GitHub Actions workflows to enable specific access levels: markdown link checks in the cron-weekly workflow, and issue/pull-request management in the stale workflow.

Changes

Cohort / File(s)	Summary
Workflow Permissions .github/workflows/cron-weekly.yml, .github/workflows/stale.yml	Added top-level permissions blocks to enable required workflow capabilities: contents: read for markdown link checks, and issues: write and pull-requests: write for issue/PR management operations.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

---

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 and usage tips.}

[coderabbitai]

🧹 Nitpick comments (1)

.github/workflows/stale.yml (1)

6-8: Permission block is correct and sufficient for actions/stale.

issues: write covers stale label operations, comments, and closing on issues; pull-requests: write covers stale label operations and comments on PRs; both are needed for remove-stale-when-updated (default true), which removes the stale label from both issues and PRs. Note that even when only processing stale PRs, issues: write is also required — which is satisfied here.

As a minor hardening note, GitHub's own documentation example for actions/stale specifically shows permissions scoped at the job level rather than the workflow level. For this single-job workflow it's functionally equivalent, but job-level scoping is the idiomatic preference.

♻️ Optional: scope permissions to the job level

-permissions:
-  issues: write # to close and label issues (actions/stale)
-  pull-requests: write # to mark stale pull requests (actions/stale)
-
 jobs:
   stale:
     runs-on: ubuntu-latest
     if: github.repository_owner == 'storybookjs'
+    permissions:
+      issues: write # to close and label issues (actions/stale)
+      pull-requests: write # to mark stale pull requests (actions/stale)
     steps:

🤖 Prompt for AI Agents

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

In @.github/workflows/stale.yml around lines 6 - 8, The permissions block is
currently defined at the workflow level (permissions: with issues: write and
pull-requests: write) which is functionally correct but the reviewer recommends
scoping to the job level; update the workflow to move the permissions block from
the top-level to the single job that runs the actions/stale step (retain issues:
write and pull-requests: write and keep remove-stale-when-updated behavior
unchanged), i.e., locate the job that invokes actions/stale and add the
permissions: { issues: write, pull-requests: write } under that job so
permissions are idiomatically scoped to the job.

🤖 Prompt for all review comments with AI agents

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

Nitpick comments:
In @.github/workflows/stale.yml:
- Around line 6-8: The permissions block is currently defined at the workflow
level (permissions: with issues: write and pull-requests: write) which is
functionally correct but the reviewer recommends scoping to the job level;
update the workflow to move the permissions block from the top-level to the
single job that runs the actions/stale step (retain issues: write and
pull-requests: write and keep remove-stale-when-updated behavior unchanged),
i.e., locate the job that invokes actions/stale and add the permissions: {
issues: write, pull-requests: write } under that job so permissions are
idiomatically scoped to the job.