Fix: External contribution tests

[Meldiron]

Summary by CodeRabbit

• Chores
  • Updated CI/CD workflow configuration for improved test execution handling.

---

Note: This release contains no user-facing changes. Updates are limited to internal testing infrastructure improvements.

[coderabbitai]

Warning

Rate limit exceeded

@Meldiron has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 20 minutes and 57 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

Walkthrough

The workflow file .github/workflows/tests.yml is modified to add event-based gating and improve security controls. The trigger configuration is expanded from a simple pull_request event to include both pull_request and pull_request_target with a labeled type filter. A permissions block is added granting read access to contents. A conditional job-level gate is introduced requiring the label name to be 'test' before execution. The checkout action is upgraded from v2 to v4 with an added ref parameter to fetch the specific PR head SHA.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'Fix: External contribution tests' clearly describes the main change—updating CI/CD workflow to handle external contributions' tests properly by adding label-based gating.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

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

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix-cicd-for-external

---

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: 2

🤖 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/tests.yml:
- Around line 5-6: The workflow uses pull_request_target while checking out
untrusted PR code (ref: github.event.pull_request.head.sha) and injects
sensitive env vars (TESTS_GITHUB_PRIVATE_KEY, TESTS_GITHUB_APP_IDENTIFIER,
TESTS_GITHUB_INSTALLATION_ID) into Docker, creating a pwn-request risk; fix by
either splitting into two workflows (unprivileged pull_request to run tests and
upload artifacts, and a privileged workflow_run that consumes artifacts) or, if
splitting is infeasible, harden this workflow: set persist-credentials: false on
the actions/checkout step, tighten the label gate (add a check that
github.event.pull_request.author_association is OWNER or COLLABORATOR and
validate github.event.actor), and avoid checking out PR-head code when secrets
are present (only checkout target/merge commit or require manual review before
enabling secret usage).
- Around line 3-6: The workflow currently defines both pull_request and
pull_request_target triggers while the job uses a condition checking
github.event.label.name == 'test' (job-level condition), which means
pull_request events (which have null label) always skip the job; remove the
unnecessary pull_request trigger declaration so only pull_request_target with
types: [labeled] remains, ensuring runs are only created on labeling events and
eliminating noisy skipped runs.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

pull_request trigger is dead code — the job-level condition is never satisfied for it

Line 4 declares pull_request: with no types: filter, so it fires for the default event types: opened, synchronize, and reopened. For all of these events, github.event.label.name is null/empty. The job-level condition on Line 16 (github.event.label.name == 'test') therefore always evaluates to false for pull_request events, meaning the job is unconditionally skipped. The trigger creates noisy "skipped" workflow runs on every PR push without ever doing useful work.

If the intent is solely to gate execution on the labeled event, remove the pull_request: line:

🧹 Proposed fix

 on:
-  pull_request:
   pull_request_target:
     types: [labeled]

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	on:
	pull_request:
	pull_request_target:
	types: [labeled]
	on:
	pull_request_target:
	types: [labeled]

🤖 Prompt for AI Agents

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

In @.github/workflows/tests.yml around lines 3 - 6, The workflow currently
defines both pull_request and pull_request_target triggers while the job uses a
condition checking github.event.label.name == 'test' (job-level condition),
which means pull_request events (which have null label) always skip the job;
remove the unnecessary pull_request trigger declaration so only
pull_request_target with types: [labeled] remains, ensuring runs are only
created on labeling events and eliminating noisy skipped runs.