Before
Developers or DevOps team members likely reviewed each opened or edited pull request, read its title and description, inspected changed files, and decided which category applied. They then manually added the appropriate label, repeating the process whenever pull request content changed.
How it works
- Receive an opened or edited pull request event and retrieve its changed files.
- Analyze the pull request title, description, and file names for bug, configuration, or security indicators.
- Apply the matching category label directly to the pull request.
Workflow details
- Event filtering: The workflow accepts GitHub pull request events and continues only when the event relates to a pull request whose action is opened or edited.
- Context collection: It retrieves the pull request's changed files and combines that information with the title and description to provide a fuller basis for classification.
- Content analysis: An AI classification stage evaluates whether the pull request relates to a bug or fix, configuration work, or a security concern, using both written content and file names.
- Automated decisions: Rule-based checks look for relevant terms in the title and description and inspect changed files for indicators such as configuration, customer-related, code ownership, or web application firewall changes.
- Label application: When a condition is met, the workflow adds the corresponding label to the pull request, including bug, config, or security categories, so the work is visibly organized in the repository.
What changed
Pull request categorization now happens automatically after an opened or edited event. The workflow performs the content and file checks consistently and updates the pull request with the applicable label, leaving people to focus on reviewing the categorized work rather than performing the initial triage.
Work removed
Reviewing qualifying pull requests one by one, retrieving and inspecting changed files, searching titles and descriptions for category indicators, deciding which label applies, and manually adding the label to the pull request.
Expected outcome
Consistent labeling of qualifying pull requests with the relevant bug, configuration, or security category, without requiring a separate manual triage and labeling pass.
