Fix the permissions in the automatic labeler

[ptrendx]

Description

Added the permission to write to the pull requests, since that is what is needed to add the existing label to a PR, rather than the issue: write, which is needed to create the new labels.

Type of change

• Documentation change (change only to the documentation, either a fix or a new content)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Infra/Build change
• Code refactoring

[greptile-apps]

Greptile Summary

This PR fixes the automatic PR labeler by adding pull-requests: write to the workflow's permission set, resolving failures when the action tried to attach existing labels to pull requests under a pull_request_target trigger.

• Adds pull-requests: write alongside the existing contents: read and issues: write permissions in .github/workflows/community_label.yml.
• The workflow logic itself is unchanged — it still classifies contributors as community-contribution or org-contribution and attaches the appropriate existing label.

Confidence Score: 4/5

Safe to merge — the change is confined to a single permission line in a CI workflow and the workflow does not execute any code from the incoming PR.

The fix is straightforward and clearly addresses the root cause. Two minor follow-up questions exist: whether issues: write is still necessary given no label creation occurs, and whether the pull_request_target + write-token combination warrants an inline comment for future maintainers. Neither blocks the merge.

.github/workflows/community_label.yml — worth confirming whether issues: write can be dropped now that pull-requests: write is present.

Important Files Changed

Filename	Overview
.github/workflows/community_label.yml	Adds pull-requests: write permission so the labeler can attach labels to PRs via the Issues API under a pull_request_target trigger; the workflow does not check out or execute any PR code.

Comments Outside Diff (1)

1. .github/workflows/community_label.yml, line 9-10 (link)

   pull_request_target with write permissions — worth a periodic audit

   pull_request_target runs in the context of the base repository and carries its secrets and write tokens even for fork PRs. Adding pull-requests: write broadens the token scope. This specific workflow is safe today because it runs only a hardcoded inline script (no checkout of PR code), but the combination is a common injection vector; any future edit that adds a checkout step or runs tooling from the PR would become a security concern. Worth noting in a comment so future contributors know the risk.

_{Reviews (1): Last reviewed commit: "Fix the permissions" | Re-trigger Greptile}

[greptile-apps]

issues: write may be redundant with this fix

The workflow only calls issues.addLabels on existing labels — it never creates new labels. The PR description states issues: write is "needed to create new labels," but no label creation happens here. If pull-requests: write is now the permission that enables addLabels on PR objects (as this fix implies), issues: write may be unnecessary and could be dropped to keep the token scope minimal.