[AlphaNen]

Description

Add a read-only top-level permissions: block to every workflow that was missing one, so GITHUB_TOKEN no longer inherits the repository's default write scopes. Workflows that check out the repo use contents: read; workflows that only write via DAPR_BOT_TOKEN (or call reusable workflows that do) use permissions: {}.

Existing job-level write grants are unchanged:

• build.yaml / build-tag.yaml codecov jobs: id-token: write
• build-tag.yaml notify-on-failure: issues: write and actions: read

Reusable workflow callers (backport.yaml, dapr-bot-schedule.yml) stay at permissions: {} because the called workflows in dapr/.github already declare permissions: {} and use DAPR_BOT_TOKEN.

Issue reference

We strive to have all PR being opened based on an issue, where the problem or feature have been discussed prior to implementation.

Please reference the issue this PR will close: #1333

Checklist

Please make sure you've completed the relevant tasks for this PR, out of the following list:

• Code compiles correctly
• Created/updated tests
• Extended the documentation

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 87.27%. Comparing base (fddc30f) to head (d0edf75).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1334   +/-   ##
=======================================
  Coverage   87.27%   87.27%           
=======================================
  Files         163      163           
  Lines       13069    13069           
=======================================
  Hits        11406    11406           
  Misses       1663     1663           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[sreyasts]

I maintain Workflow Lens, an AI-assisted local workflow reviewer. I used it to compare all eight changed workflows at fddc30f → d0edf75 for this PR.

Two useful review checks:

• build.yaml and build-tag.yaml: the build jobs keep their explicit contents: read + id-token: write. build-tag.yaml also keeps notify-on-failure at issues: write + actions: read.
• release-tag.yaml: the tag job already explicitly requested contents: read, so the new workflow default does not change that job's requested scopes.

Where an old workflow omitted permissions, the comparison keeps the baseline as unknown; it cannot establish the old repository-default budget. It also does not resolve access through DAPR_BOT_TOKEN or prove runtime behavior.

Would you try one actual comparison and tell me whether it adds anything beyond GitHub's diff?

For build-tag.yaml: open the old file, paste it into Workflow Lens, choose Use current as baseline, then paste the proposed file. It runs locally without sign-in or workflow uploads.

One confusing/wrong result—or “the normal diff is easier”—would help. No endorsement or star needed.

[acroca]

This can go now that we have it in the top level, right?

[AlphaNen]

Good catch — removed the job-level permissions on tag so contents: read only lives at the workflow top level. Pushed in c99e480.