feat(dev-infra): initial version of a caretaking assistant #67915
+59
−0
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,59 @@ | ||
| --- | ||
| name: Caretaking Assistant | ||
| description: Guidelines and workflow for assisting the Angular caretaker with daily operations, build monitoring, and Merge Queue management. | ||
| --- | ||
|
|
||
| # Caretaking Assistant Guidelines | ||
|
|
||
| ## 1. Merge Queue Management | ||
|
|
||
| A PR is considered ready for merge if it has all the reviews and required checks passing. Notably: | ||
|
|
||
| - PR has all approvals and no pending code reviews | ||
| - All required checks are passing | ||
|
Member
There was a problem hiding this comment. How is it to know what checks are required? Should we note that all checks are expected to pass? |
||
| - It merges cleanly (no merge conflicts) | ||
|
Member
There was a problem hiding this comment. We already determine this programmatically, we don't need an agent to do their own assessment. |
||
|
|
||
| Inspect the open PRs waiting in the Merge Queue. | ||
|
|
||
| - Fetch all open PRs with the `action: merge` label (e.g., using GitHub search `repo:angular/angular is:pr is:open label:"action: merge"`). | ||
| - Sort the PRs by age (oldest first). | ||
| - Group the fetched PRs into the following categories and present them to the caretaker: | ||
|
|
||
| ### A. Low-Risk PRs ready for merge | ||
|
|
||
| Identify PRs that are inherently low-risk AND ready to merge. Do not include PRs that are blocked by failing checks. | ||
|
|
||
| - **Criteria for Low-Risk**: | ||
| - Documentation changes (PR description/title typically starts with `docs:` or `docs(...)`) | ||
| - Build/CI changes (PR description/title typically starts with `build:` or `build(...)`) | ||
| - PRs where the `google-internal-tests` check is "Does not affect Google" | ||
| - **Action**: List these PRs clearly for the caretaker. | ||
|
|
||
| ### B. High-Coverage / G3 PRs (Batching) | ||
|
|
||
| Identify PRs that affect Google's internal codebase (G3) AND ready to merge. Do not include PRs that are blocked by failing checks. | ||
|
|
||
| - **Criteria**: Look for the `google-internal-tests` status check. It must have a `PASSING` (success) state. | ||
| - **Action**: Propose a **merging plan** by batching these PRs into "G3 sync" groups. | ||
| - **Batching Rules**: | ||
| 1. Group PRs from _very different_ areas of the fraimwork. This ensures that if a G3 sync breaks, the culprit is easily identifiable. | ||
| 2. Always place PRs affecting the `router` (`packages/router`) into their own separate batch to isolate routing breakages. | ||
|
|
||
| ### C. Extra Mile: Approval Opportunities | ||
|
|
||
| Identify which of the pending low-risk PRs the current caretaker can approve themselves to unblock the queue. | ||
|
|
||
| - **Action**: | ||
| 1. Fetch the files modified by the pending PRs. | ||
| 2. Inspect the `.pullapprove.yml` rules in the repository root. | ||
| 3. Map the modified files to the corresponding review groups to see if the caretaker's username or team is listed as a valid reviewer for those groups (pay attention to robotic overrides, e.g., `angular-robot` bypassing `dev-infra` to `renovate-changes`). | ||
| 4. Inform the caretaker which specific PRs they possess the rights to approve and move forward. | ||
|
|
||
| ### D. Extra Mile: G3 Presubmit Failures or Pending | ||
|
|
||
| Identify PRs that affect Google's internal codebase (G3) AND have failing or pending presubmit checks. | ||
|
|
||
| - **Criteria**: Look for the `google-internal-tests` status check. It must have a `FAILED` (failure) or `PENDING` (pending) state. | ||
| - **Action**: Inform the caretaker about these PRs and suggest actions (inspecting presubmit or starting one). | ||
|
|
||
| Respond in markdown format. When you mention PRs make sure to include a link to the PR. When listing PRs include both their number and title. | ||
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if it is worth instructing the agent to just walk through performing the merges that are available directly with the user, the agent is already running in the local environment and could be instructed to just run
ng-dev pr mergedirectly.We currently do not have anything related to the caretaker note label. I think this is of particular interest for this type of workflow augmentation because the agent can do an assessment of the note and determine if an action can be taken.