fix(ci): use pull_request_target so labeler works on fork PRs

[nikolasdehor]

Resumo

• Corrige o workflow de labeling que falhava silenciosamente em PRs de forks
• Troca trigger de pull_request para pull_request_target (o evento pull_request dá token read-only para forks, então addLabels falhava)
• Substitui git diff por chamada à API do GitHub para detecção de mudanças em squads (forks não têm acesso ao histórico de branches remotas)
• Adiciona permissão issues: write necessária para adicionar labels
• Adiciona await na chamada addLabels

Closes #479

Nota de segurança

pull_request_target executa no contexto do repo base. O workflow atual apenas faz checkout de código (read-only) e adiciona labels — não executa scripts não-confiáveis. Se no futuro adicionar steps que executam código do PR, considerar pull_request + workflow_run pattern.

Plano de teste

• Validação manual da sintaxe YAML
• Verificar que permissões estão corretas
• Verificar que chamada à API substitui corretamente o git diff

[vercel]

@nikolasdehor is attempting to deploy a commit to the Pedro Valério Lopez's projects Team on Vercel.

A member of the Team first needs to authorize it.

[coderabbitai]

Walkthrough

Updated the PR-labeling GitHub Actions workflow to run on pull_request_target, switch squad-file detection from a shell git diff to actions/github-script using the GitHub API, set outputs via core.setOutput, and use context.payload.pull_request.number when adding labels.

Changes

Cohort / File(s)	Summary
Workflow Event & Script Updates .github/workflows/pr-labeling.yml	Trigger changed from pull_request to pull_request_target. Replaced shell-based git diff with actions/github-script to enumerate PR files and detect squads/ changes. Switched output plumbing to core.setOutput and updated PR-number reference to context.payload.pull_request.number. Added explicit issues: write permission.

Sequence Diagram(s)

mermaid
sequenceDiagram
participant ForkContributor as Fork PR (head)
participant Repo as Base Repo (pull_request_target)
participant Runner as Actions Runner
participant GHAPI as GitHub API
participant Labeler as Label step

ForkContributor->>Repo: Open PR (fork)
Repo->>Runner: Start workflow (pull_request_target)
Runner->>GHAPI: List PR files via API (actions/github-script)
GHAPI-->>Runner: Files list
Runner->>Runner: Check for squads/ path, setOutput(has_squad)
Runner->>Labeler: Request label add (uses context.payload.pull_request.number)
Labeler->>GHAPI: Add needs-po-review label
GHAPI-->>Labeler: Confirm label added

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Suggested labels

ci/cd, workflows

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and accurately summarizes the main change: switching from pull_request to pull_request_target to enable the labeler to work on fork PRs.
Linked Issues check	✅ Passed	All primary objectives from issue #479 are met: trigger changed to pull_request_target, git-diff replaced with GitHub API calls for file detection, permissions block added, and security preserved.
Out of Scope Changes check	✅ Passed	All changes directly address the linked issue #479 requirements with no unrelated modifications; updates are focused on the labeler workflow and its dependencies.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

• 📝 Generate docstrings (stacked PR)
• 📝 Generate docstrings (commit on current branch)

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

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]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

.github/workflows/pr-labeling.yml (1)

17-19: ⚠️ Potential issue | 🟡 Minor

Consider adding issues: write permission.

The official actions/labeler documentation states: "To ensure the action works correctly, include the following permissions in your workflow file: contents: read, pull-requests: write, issues: write." The missing issues: write scope could cause silent failures if the labeler needs to create a label that doesn't yet exist in the repository.

🛡️ Proposed fix

     permissions:
       contents: read
       pull-requests: write
+      issues: write

🤖 Prompt for AI Agents

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

In @.github/workflows/pr-labeling.yml around lines 17 - 19, The workflow's
permissions block is missing the issues write scope which can prevent
actions/labeler from creating labels; update the permissions map to include
issues: write alongside contents: read and pull-requests: write so the labeler
can create and manage labels when needed, i.e., add the "issues" permission with
"write" access in the permissions block.

🧹 Nitpick comments (1)

.github/workflows/pr-labeling.yml (1)

21-22: Security advisory: never add a fork ref to this checkout step.

There is a potentially dangerous misuse of the pull_request_target trigger that may allow malicious PR authors to obtain write permissions or steal secrets. It is advisable to only use pull_request_target in workflows carefully designed to avoid executing untrusted code.

The current checkout (no explicit ref) is safe because it checks out the base branch. If this step is ever extended, ensure the ref is never set to github.event.pull_request.head.sha or github.event.pull_request.head.ref, as doing so would check out untrusted fork code in a privileged context.

🤖 Prompt for AI Agents

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

In @.github/workflows/pr-labeling.yml around lines 21 - 22, The workflow uses
the pull_request_target trigger and the checkout step (uses:
actions/checkout@v4); ensure you never set the checkout ref to the PR head
(github.event.pull_request.head.sha or .head.ref) which would check out
untrusted fork code in a privileged context—keep the step without a ref (so it
checks out the base) or explicitly set it to the base ref
(github.event.pull_request.base.sha or .base.ref) and audit any future changes
to the Checkout step to avoid adding head refs.

🤖 Prompt for all review comments with AI agents

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

Inline comments:
In @.github/workflows/pr-labeling.yml:
- Around line 49-54: The call to github.rest.issues.addLabels(...) is missing an
await so any rejection will be unobserved; update the workflow action to await
the Promise returned by github.rest.issues.addLabels (or return it from the
async function) so failures propagate and the step fails on error, ensuring the
API call is properly awaited and errors are not silently swallowed.

---

Outside diff comments:
In @.github/workflows/pr-labeling.yml:
- Around line 17-19: The workflow's permissions block is missing the issues
write scope which can prevent actions/labeler from creating labels; update the
permissions map to include issues: write alongside contents: read and
pull-requests: write so the labeler can create and manage labels when needed,
i.e., add the "issues" permission with "write" access in the permissions block.

---

Nitpick comments:
In @.github/workflows/pr-labeling.yml:
- Around line 21-22: The workflow uses the pull_request_target trigger and the
checkout step (uses: actions/checkout@v4); ensure you never set the checkout ref
to the PR head (github.event.pull_request.head.sha or .head.ref) which would
check out untrusted fork code in a privileged context—keep the step without a
ref (so it checks out the base) or explicitly set it to the base ref
(github.event.pull_request.base.sha or .base.ref) and audit any future changes
to the Checkout step to avoid adding head refs.

[Copilot]

Pull request overview

This PR fixes the Resource not accessible by integration error that occurs on all fork PRs during the labeler CI step. The issue stems from GitHub's security restriction where the pull_request event provides only read-only GITHUB_TOKEN permissions for fork PRs, which cannot be overridden by workflow permissions.

Changes:

• Changed workflow trigger from pull_request to pull_request_target to run with base repository context and full write permissions
• Replaced git diff shell command with GitHub API call (github.rest.pulls.listFiles()) for squad change detection, since pull_request_target doesn't expose fork commits
• Updated context references to use context.payload.pull_request.number for explicit PR number access

Comments suppressed due to low confidence (2)

.github/workflows/pr-labeling.yml:50

• Consider using context.issue.number instead of context.payload.pull_request.number for consistency with other workflows in this repository. Both pr-automation.yml (lines 101, 120) and welcome.yml (lines 82, 93) use context.issue.number when referencing pull request numbers. While context.payload.pull_request.number is valid and works correctly, using context.issue.number would maintain consistency across the codebase.

              issue_number: context.payload.pull_request.number,

.github/workflows/pr-labeling.yml:39

• For consistency, consider using context.issue.number instead of context.payload.pull_request.number. This would align with the pattern used in other workflows like pr-automation.yml (lines 101, 120) and welcome.yml (lines 82, 93). While both approaches work correctly, context.issue.number is the established convention in this codebase for referencing pull request numbers.

              pull_number: context.payload.pull_request.number,

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.