[pipeline] Use GHA workflow triggers to run labeler workflow

[yuxiqian]

A workaround for workflow failure introduced in #4263.

[Copilot]

Pull request overview

This PR implements a security improvement for the labeler workflow by splitting it into a trigger workflow and a main workflow, following the workflow_run pattern. This addresses security concerns introduced in PR #4263 by ensuring that workflows with write permissions (like applying labels to PRs) run in the context of the default branch rather than in the PR branch context, preventing potential malicious code in PRs from accessing write tokens.

Changes:

• Created new label_trigger.yml workflow that triggers on pull_request events targeting master and release-* branches
• Modified label.yml to use workflow_run trigger instead of direct pull_request trigger, and added explicit permissions declarations

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
.github/workflows/label_trigger.yml	New trigger workflow that runs on pull_request events with minimal permissions, triggering the main labeler workflow via workflow_run
.github/workflows/label.yml	Changed from direct pull_request trigger to workflow_run trigger, added workflow-level and job-level permissions declarations

---

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

[Copilot]

The comment references ".github/label.yml" but the actual configuration file appears to be ".github/labeler.yml" (as evidenced by the file existing in the repository). This documentation discrepancy could cause confusion for maintainers.

Suggested change

	# To use this workflow, you will need to set up a .github/label.yml
	# To use this workflow, you will need to set up a .github/labeler.yml

[Copilot]

Permissions are specified at both the workflow level (lines 30-33) and job level (lines 38-41). This duplication is redundant when the permissions are identical. Consider removing the job-level permissions declaration to match the pattern used in approve_label.yml, which only specifies permissions at the workflow level.

Suggested change

	permissions:
	checks: write
	contents: read
	pull-requests: write

[Copilot]

When using workflow_run triggers, the labeler action needs access to the pull request context to apply labels. While actions/labeler@v6 has support for workflow_run events, it relies on github.event.workflow_run.pull_requests being populated.

This should work since the triggering workflow (Labeler-Trigger) is triggered by pull_request events. However, unlike approve_label.yml which explicitly retrieves PR context using get-workflow-origin (lines 42-47), this implementation relies on the labeler action's built-in workflow_run support.

Consider testing this thoroughly, or add explicit PR context retrieval similar to approve_label.yml to ensure the labeler can identify which PR to label in all cases.

Suggested change

	types: [requested]
	types: [completed]