chore: Add workflow to auto-label community PRs from forks

[Aaron ("AJ") Steers (aaronsteers)]

Summary

Adds a GitHub Actions workflow that automatically applies the community label to PRs opened from forks. This enables automatic tracking on the Community PRs project board.

The workflow:

• Triggers on pull_request_target events (opened and reopened)
• Only runs for PRs from forks (via if: github.event.pull_request.head.repo.fork == true)
• Uses the actions-ecosystem/action-add-labels marketplace action (v1.1.3, pinned by SHA)
• The action's addLabels API is idempotent—if the label already exists, it succeeds without error

Review & Testing Checklist for Human

• Verify the workflow does NOT checkout or execute any code from the fork (security requirement for pull_request_target)
• Confirm the community label exists in this repository
• Verify the pinned action SHA (bd52874380e3909a1ac983768df6976535ece7f8) matches v1.1.3

Test plan: After merging, open a PR from a fork (or close/reopen an existing fork PR) to verify the label is applied automatically.

Notes

This workflow cannot be tested via CI since it only triggers on actual fork PRs.

Requested by: Aaron ("AJ") Steers (@aaronsteers) (AJ Steers)
Devin session: https://app.devin.ai/sessions/b0784474061f4084a04ce5251ce1e9f2

Important

Auto-merge enabled.

This PR is set to merge automatically when all requirements are met.

Summary by CodeRabbit

• Chores
  • Pull requests opened from forked repositories are automatically labeled "community" to improve organization and visibility. Labeling occurs on PR open/reopen to ensure consistent identification of community contributions.

✏️ Tip: You can customize this high-level summary in your review settings.

Note

Auto-merge may have been disabled. Please check the PR status to confirm.

[devin-ai-integration]

Original prompt from AJ Steers

Received message in Slack channel #community-open-source:

@Devin - Please update our workflows so that new PRs from forks automatically are labeled (in not already) and we'll auto-add by label to a specific project board (projects v2).
Thread URL: https://airbytehq-team.slack.com/archives/C06EVC83UGH/p1765393144180229

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring

[github-actions]

👋 Greetings, Airbyte Team Member!

Here are some helpful tips and reminders for your convenience.

Testing This PyAirbyte Version

You can test this version of PyAirbyte using the following:

# Run PyAirbyte CLI from this branch:
uvx --from 'git+https://github.com/airbytehq/PyAirbyte.git@devin/1765396924-label-community-prs' pyairbyte --help

# Install PyAirbyte from this branch for development:
pip install 'git+https://github.com/airbytehq/PyAirbyte.git@devin/1765396924-label-community-prs'

Helpful Resources

• PyAirbyte Documentation
• API Reference

PR Slash Commands

Airbyte Maintainers can execute the following slash commands on your PR:

• /fix-pr - Fixes most formatting and linting issues
• /poetry-lock - Updates poetry.lock file
• /test-pr - Runs tests with the updated PyAirbyte

Community Support

Questions? Join the #pyairbyte channel in our Slack workspace.

📝 Edit this welcome message.

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds a GitHub Actions workflow that auto-labels pull requests from forked repositories with "community". It triggers on pull_request_target (opened, reopened), runs on ubuntu-24.04, checks that the PR is from a fork, and uses actions-ecosystem/action-add-labels with write permissions to apply the label idempotently.

Changes

Cohort / File(s)	Summary
GitHub Actions workflow for community PR labeling ​.github/workflows/label-community-prs.yml	New workflow that labels PRs from forks with community. Triggers on pull_request_target for opened and reopened, runs on ubuntu-24.04, grants write access to issues and pull-requests, performs a fork check, and uses actions-ecosystem/action-add-labels to apply the label idempotently.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

• Check workflow syntax, pull_request_target semantics, and permissions scopes.
• Verify the fork-check correctly identifies forked PRs and avoids false positives (e.g., maintainer-created branches from forks).
• Confirm the selected actions-ecosystem/action-add-labels version/config and idempotency behavior.
• Suggestion: add a brief inline comment explaining the fork check rationale and safety trade-offs, wdyt?

Pre-merge checks and finishing touches

✅ 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 accurately summarizes the main change: adding a GitHub Actions workflow to automatically label community PRs from forks.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch devin/1765396924-label-community-prs

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between e30baeb and aeb0baa.

📒 Files selected for processing (1)

• .github/workflows/label-community-prs.yml (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• .github/workflows/label-community-prs.yml

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (6)

• GitHub Check: Pytest (Fast)
• GitHub Check: Pytest (All, Python 3.10, Windows)
• GitHub Check: Pytest (No Creds)
• GitHub Check: Pytest (All, Python 3.11, Windows)
• GitHub Check: Pytest (All, Python 3.10, Ubuntu)
• GitHub Check: Pytest (All, Python 3.11, Ubuntu)

---

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

🧹 Nitpick comments (1)

.github/workflows/label-community-prs.yml (1)

16-16: Confirm the "community" label exists in the repository.

The workflow assumes the "community" label already exists and will apply it idempotently. Per the PR checklist, have you verified that this label exists in your repo's label configuration? If it doesn't exist yet, the API will auto-create it with default styling, which may not match your team's conventions.

Would you like me to help verify this or generate a script to check/create the label?

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 1b48476 and c16d6e8.

📒 Files selected for processing (1)

• .github/workflows/label-community-prs.yml (1 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (6)

• GitHub Check: Pytest (All, Python 3.10, Ubuntu)
• GitHub Check: Pytest (All, Python 3.11, Ubuntu)
• GitHub Check: Pytest (All, Python 3.10, Windows)
• GitHub Check: Pytest (All, Python 3.11, Windows)
• GitHub Check: Pytest (No Creds)
• GitHub Check: Pytest (Fast)

🔇 Additional comments (2)

.github/workflows/label-community-prs.yml (2)

1-27: Solid security posture for auto-labeling fork PRs.

The workflow correctly uses pull_request_target without any code checkout, which is the recommended pattern for safe operations like labeling and commenting on fork PRs. The fork PR labeling use case is exactly what pull_request_target was designed for — to label PRs without processing dangerous code. The fork guard on line 16 and minimal permissions are well-executed.

---

6-10: Trigger configuration is appropriate.

The opened and reopened event types are the right choice for this use case — they cover the full lifecycle of a fork PR coming back into focus.

[github-actions]

PyTest Results (Fast Tests Only, No Creds)

348 tests  ±0   348 ✅ ±0   6m 2s ⏱️ -6s
  1 suites ±0     0 💤 ±0 
  1 files   ±0     0 ❌ ±0 

Results for commit aeb0baa. ± Comparison against base commit 1b48476.

♻️ This comment has been updated with latest results.