Custom agent for backporting servicing PRs

[roji]

Current (temporary) limitations:

• Does not yet perform testing against actual databases
• Uses a personal access token

[Copilot]

Pull request overview

This PR introduces a GitHub Agentic Workflow for automating the backporting of PRs from the main branch to servicing/release branches. The workflow leverages GitHub Copilot CLI to analyze merged PRs and create backport PRs with appropriate quirk switches for safe rollback capability.

Changes:

• Adds an agentic workflow configuration that responds to /backport slash commands in PR comments
• Implements automatic quirk generation for servicing fixes, allowing runtime opt-out via AppContext switches
• Configures the workflow to create draft PRs with proper labels, reviewers, and detailed servicing templates
• Uses a temporary personal access token (ROJI_TOKEN) until an organization token is available

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
.github/workflows/backport-for-servicing.md	Main workflow configuration defining backport logic, quirk guidelines, and PR template structure
.github/workflows/backport-for-servicing.lock.yml	Auto-generated GitHub Actions YAML workflow (1200+ lines) with full job definitions and configurations
.github/aw/actions-lock.json	Version pinning for GitHub Actions used in the workflow
.gitattributes	Marks .lock.yml files as auto-generated and sets merge strategy to "ours"

Comments suppressed due to low confidence (7)

.github/workflows/backport-for-servicing.md:88

• There is a grammar error: "if a test was indeed was added" has a duplicate "was". It should be "if a test was indeed added".

State simply that "a test was added" if a test was indeed was added. If test coverage is unfeasible for some reason, briefly mention that and provide reasons why.

.github/workflows/backport-for-servicing.md:92

• There is a grammar error: "mentioned" should be "mention" to match the other imperative verbs in this sentence ("rank", "mention").

Post a brief risk assessment, and rank the risk from "extremely low" to "high", taking into account the amount of code changed. If the fix is basically a one-liner, mention that. If you've added a quirk as detailed above, mentioned "Quirk added".

.github/workflows/backport-for-servicing.md:96

• There is a spelling error: "cmomas" should be "commas".

* The `ISSUE_NUMBER` value should be the issue closed by the originating PR (the one that is being backported). If the originating PR closes multiple issues, list those out separated by cmomas.

.github/workflows/backport-for-servicing.md:33

• The sentence on line 33 appears to be incomplete. It reads "This workflow analyzes an existing PR - typically merged to main - and submits a new PR which backports the same changes to a" but does not finish. This should be completed, for example: "...to a servicing/release branch."

This workflow analyzes an existing PR - typically merged to main - and submits a new PR which backports the same changes to a 

.github/workflows/backport-for-servicing.md:42

• The wording "reduces the patch fix" is unclear. Consider rephrasing to "reduces the risk of the patch" or "mitigates the risk of the fix" to make the meaning clearer.

A "quirk" is a .NET appcontext switch that we add in backport fixes which allows the user to opt out of the fix at runtime; this reduces the patch fix, as if a bug is introduced, users can simply disable the patch. Add a quirk for all cases where it makes sense; avoid adding a quirk when the fix is 100% obvious and risk-free, or when adding the quirk would simply cause another failure/exception to occur immediately.

.github/workflows/backport-for-servicing.md:19

• The reviewers field appears to have a space-separated list instead of proper array syntax. It should be either reviewers: [efteam, art83] (two separate reviewers) or if "efteam art83" is a single reviewer, it should be reviewers: ["efteam art83"]. Verify the intended format for the reviewers field.

    reviewers: [efteam art83]

.github/workflows/backport-for-servicing.md:38

• The pattern description release/XX.0 where "X is the greatest" is ambiguous. The notation XX typically means two digits (like 10, 11, etc.), but the phrase "where X is the greatest" uses singular "X". Consider clarifying this to something like: "find the latest release branch matching release/N.0 (where N is the highest major version number)" or "release branches like release/10.0, release/11.0, etc., choosing the one with the highest version".

* If the user hasn't specified which branch to port to, find the latest release branch that corresponds to the pattern `release/XX.0` (where X is the greatest). Ignore other branches such as `release/11.0-preview2`.

[Copilot]

Pull request overview

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

Comments suppressed due to low confidence (6)

.github/workflows/backport-for-servicing.md:26

• The workflow grants discussions: write (in the compiled lock workflow) even though this workflow appears to only operate on PRs/issues. If discussions aren’t needed, configure the safe-outputs add-comment tool with discussions: false (per the tool description) to avoid requesting unnecessary write permissions.

  # Allow adding a comment in case of failure
  add-comment:
    hide-older-comments: true    # hide previous comments from same workflow
    allowed-reasons: [outdated]

.github/workflows/backport-for-servicing.md:32

• This sentence is incomplete (it ends with a dangling "to a"); that makes the workflow instructions unclear for the agent/user. Please finish the sentence (e.g., explicitly mention backporting to a servicing/release branch).

This workflow analyzes an existing PR - typically merged to main - and submits a new PR which backports the same changes to a 

.github/workflows/backport-for-servicing.md:96

• The template markers don’t match: it starts with <START_OF_TEMPLATE> but ends with </END_OF_TEMPLATE>. Since the agent is instructed to follow this template strictly, mismatched markers can cause confusion or brittle parsing. Make the start/end markers consistent (and avoid mixing opening/closing tag syntax if these are meant to be literal delimiters).

The contents of the PR should strictly follow the following template:

<START_OF_TEMPLATE>
Fixes #<ISSUE_NUMBER>
Backports #<TRIGGERING_PR_NUMBER>

**Description**

Provide information on the bug, why it occurs, how and when it was introduced.

**Customer impact**

Information about how the bug affects actual users, without internal technical detail. If possible, post a short (3-4 lines) code sample that shows when the error occurs.

If the bug causes any sort of data corruption (incorrect data being saved or returned by EF), clearly and explicitly specify that as these bugs are severe. If the bug has no feasible workaround (or the workaround is hard or undiscoverable), mention that too.

**How found**

Read the originating issue to understand how the bug was discovered; if a user filed the issue, mention "User reported on <VERSION>", and if multiple users signaled that they're affected by the issue, mention that.

**Regression**

Whether this bug represents a regression from an earlier EF version or not.

**Testing**

State simply that "a test was added" if a test was indeed was added. If test coverage is unfeasible for some reason, briefly mention that and provide reasons why.

**Risk**

Post a brief risk assessment, and rank the risk from "extremely low" to "high", taking into account the amount of code changed. If the fix is basically a one-liner, mention that. If you've added a quirk as detailed above, mentioned "Quirk added".

</END_OF_TEMPLATE>

* The `ISSUE_NUMBER` value should be the issue closed by the originating PR (the one that is being backported). If the originating PR closes multiple issues, list those out separated by cmomas.

.github/workflows/backport-for-servicing.md:97

• Typo: "cmomas" should be "commas".

* The `ISSUE_NUMBER` value should be the issue closed by the originating PR (the one that is being backported). If the originating PR closes multiple issues, list those out separated by cmomas.
* The <TRIGGERING_PR_NUMBER> value should be the triggering PR, the one being backported.

.github/workflows/backport-for-servicing.md:21

• reviewers: [efteam art83] is parsed as a single string (confirmed by the compiled lock workflow showing reviewers: ["efteam art83"]), so reviewer assignment will likely fail. Use a proper YAML sequence (e.g., reviewers: [efteam, art83] or one-per-line) so the team and user are separate entries.

  create-pull-request:
    reviewers: [efteam art83]
    draft: true
    fallback-as-issue: false
    # TEMPORARY, until we get an org token
    github-token: ${{ secrets.ROJI_TOKEN }}

.github/workflows/backport-for-servicing.md:93

• Spelling/grammar issues in the PR template instructions reduce clarity: "was indeed was added" has a duplicated "was", and "mentioned "Quirk added"" should be "mention".

State simply that "a test was added" if a test was indeed was added. If test coverage is unfeasible for some reason, briefly mention that and provide reasons why.

**Risk**

Post a brief risk assessment, and rank the risk from "extremely low" to "high", taking into account the amount of code changed. If the fix is basically a one-liner, mention that. If you've added a quirk as detailed above, mentioned "Quirk added".

[roji]

@AndriySvyryd as discussed, redid this as a custom agent instead of a slashcommand-driven agentic workflow.

[AndriySvyryd]

This is ok, but I think a skill would be better:

• It can be used for backports and new PRs
• Is exposed as a slashcommand in VS Code
• Doesn't need a specific token

See #37768