Fix: Set GitHub Workflow Token Permissions to Read-Only by Default

[intojhanurag]

Thank you for contributing to Harbor!

Description

Set all affected workflows to use read-only GITHUB_TOKEN by default and scope elevated permissions only at job level where required.

Issue

Fixes #22760

Please indicate you've done the following:

• Well Written Title and Summary of the PR
• Label the PR as needed. "release-note/ignore-for-release, release-note/new-feature, release-note/update, release-note/enhancement, release-note/community, release-note/breaking-change, release-note/docs, release-note/infra, release-note/deprecation"
• Accepted the DCO. Commits without the DCO will delay acceptance.
• Made sure tests are passing and test coverage is added if needed.
• Considered the docs impact and opened a new docs issue or PR with docs changes if needed in website repository.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 65.90%. Comparing base (c8c11b4) to head (c6fa00c).
⚠️ Report is 651 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff             @@
##             main   #22776       +/-   ##
===========================================
+ Coverage   45.36%   65.90%   +20.53%     
===========================================
  Files         244     1074      +830     
  Lines       13333   116563   +103230     
  Branches     2719     2939      +220     
===========================================
+ Hits         6049    76817    +70768     
- Misses       6983    35488    +28505     
- Partials      301     4258     +3957     

Flag	Coverage Δ
unittests	65.90% <ø> (+20.53%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.
see 989 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[intojhanurag]

Hey @bupd, I have a confusion:
If I give a top-level permission like contents: read, and then specify new permissions at the job level:
permissions:
will the top-level permission be reset, or will it still apply and we don't need to give that permission again ?

[bupd]

Hey @bupd, I have a confusion:
If I give a top-level permission like contents: read, and then specify new permissions at the job level:
permissions:
will the top-level permission be reset, or will it still apply and we don't need to give that permission again ?

job level will override the top level permissions - I guess its better to set only job level permissions (ie., remove the top level permission)

[intojhanurag]

Hey @bupd , I switched the permission from top level to job level in every file , PTAL :)

[bupd]

@intojhanurag can you also do the check by doing a release on your fork, making sure the release and build package works as expected.

[bupd]

/lgtm,
Thanks @intojhanurag for your contributions

[intojhanurag]

Hey @bupd , All scanning related workflow has been passed . That one you can see failed , it is due to Aws credential :)