[Marko Aleksandric (AleksandricMarko)]

What & why

Add a separate workflow for extensibility-request backports, without changing the existing per-issue or per-team implementation workflows.

• On Sunday at 21:10 Europe/Copenhagen, select unprocessed PRs merged into main during the rolling last 15 days. The overlapping window allows a later run to catch work missed by a prior run.
• Include event-request, request-for-external, or both, but reject other request categories. Linked original issues retain the same category checks.
• Group clean whole PRs by the main PR's Team: label and release target. Apply sources oldest first, with one provenance commit per source.
• Create one shared Task per target branch and exact release milestone, reused across teams, weekly runs and manual runs. Its table contains original issue links and title-derived summaries, original main PR links, teams and backport PR links.
• Create one draft release PR per clean team batch. Keep team/date PR titles independent of the shared tracker title.
• Select the milestone using repoVersion from the target branch's .github/AL-Go-Settings.json, exactly as Work Item Validation does. 29.1 means Version 29.1, even when 29.2 and later milestones are open.
• Reopen an existing closed tracker when adding work to an open milestone; never replace it with another Task for the same branch/milestone. A new release version gets a new tracker.
• Inherit deduplicated original-issue labels and add ext-backporting, excluding ext-ready-to-implement and source-only ext-backport-processed. The shared tracker also excludes Team:* and Ownership:*; teams belong in the table.
• Exclude ext-backporting issues from Team Ownership Classification, including manual dispatch and stale event payloads. Backport PR ownership classification is unchanged.
• Handle missing, multiple, or inconsistent team metadata independently. Conflicts and already-present sources get rows in the same milestone Task, without separate issues or empty PRs; clean team sources can still publish.
• Select the numerically highest existing releases/<number>.x branch by default, with an optional repository override. Existing requests retain their original target and membership.
• Add only ext-backport-processed to original main PRs, after confirming their backport PR exists, and exclude those sources from future automatic selection. No temporary or versioned source labels are used; conflicts/no-ops without a PR do not receive this label.
• Do not poll or update merge status. There is no daily reconciliation job, merge-status labeling, or automatic tracking-Task closure when a backport merges.
• Allow manual runs with an optional main PR number: blank = normal 15-day team processing, number = that selected source, bypassing date/category filters but preserving safety and duplicate checks. All manual runs publish; there is no dry-run mode.

Preparation uses native Git, a read-only workflow token, and an isolated sparse checkout. Publication mints a fresh repository-scoped token using the existing extensibility GitHub App. No AI resolver, Copilot token, Azure login, or execution of source content is involved.

The tracker is a mutable milestone index, while per-request journals preserve immutable source PR/merge-SHA membership, target, milestone, outcomes and PR-publication intent. Publication checks existing open/closed objects and expected App authorship and reads back pushed refs. It never force-pushes or automatically retries a creation POST within a run. Legacy App-authored independent records remain recognizable; human-authored demonstration objects are not silently adopted.

Branch names

Single original PR 11166: bc-extrequest-backport/backport_11166. The number is the original main PR number, not a linked issue number.

SCM team batch: bc-extrequest-backport/scm-2026-10-21. Team names are normalized to safe lowercase slugs; dates use the frozen Copenhagen discovery date.

If a different backport already uses or reserves a name, select -2, -3, and so on. A retry uses its saved branch, even after the date changes. Existing PRs, branch references and legacy records are not renamed or overwritten.

Description format

Tracker title: [Backporting][releases/29.x][Extensibility Requests][Version 29.1].

Tracker table: Original issue | Original PR | Team | Backport PR, followed by italic "Auto-generated content". Multiple original issues can reference the same team backport PR; retries update/deduplicate rows without dropping earlier batches.

Team PR titles retain [Backport 29.x] [Extensibility Requests] [Team: SCM] till 2026-10-21, using the Copenhagen discovery date and retaining it for retries.

PR descriptions retain Issues: and PRs:, Fixes #<shared-tracker> and the Important AI-generated disclaimer. Source merge hashes and journal metadata are hidden. Fixes targets the new shared Task, never the original issues. Release-branch PRs do not automatically close the shared Task.

Linked work

AB#649354 - Deliverable: Automated backport of Extensibility requests.

How I validated this

• Parsed the workflow using the existing YAML tooling and checked weekly-only scheduling, optional manual source, unconditional publication after preparation, and removal of preview/reconciliation wiring.
• Ran 173 targeted offline Pester tests covering policy, grouping, real cumulative Git preparation, isolated conflicts, immutable resume, publication-intent recovery, milestone selection, shared tracking, legacy/manual compatibility, exact single source-label payloads, ownership preflight and absence of merge lifecycle changes.
• Ownership regressions execute the actual preflight JavaScript with Node's built-in mocks: automatic/manual/stale/closed/case-insensitive backport trackers are skipped; ordinary issues and backport PRs retain normal classification. The targeted workflow runs these alongside the engine tests and triggers for changes to either workflow.
• The targeted hosted workflow passed on commit 7fb9b7df967deb24a213b4dd5c5017107e216860, including the expanded sparse checkout and combined engine/ownership suite.
• Live read-only discovery produced two team cohorts and one independent team-metadata exception. Prepared all five SCM source PRs cumulatively against releases/29.x successfully, and prepared [Extensibility Request] issue 11570: expose purchase line to mixed drop shipment event #11608 independently because its PR and original issue have different team labels.
• Repeated live read-only discovery with the milestone engine: three requests, all pinned to releases/29.x, Version 29.1, milestone 39. The workflow matrix round-trip retained all requests and used only 3,756 UTF-16 bytes; no publication was invoked.
• A previous personal-account publication test created Task [Backport 29.x] #11046: [Extensibility Request] issue 10889: expose large text modal helper #13110 and draft backport [Backport 29.x] #11046: [Extensibility Request] issue 10889: expose large text modal helper #13111 for source [Extensibility Request] issue 10889: expose large text modal helper #11046. The source issue was unchanged and the main PR received only ext-backport-processed. These remain legacy personal test objects, not a production-created milestone tracker.
• This milestone update does not publish additional backports or migrate those demonstration objects.
• Hosted GitHub App publication and release CI acceptance remain pending deployment approval.

No AL source is changed, so an application build or Business Central runtime test is not applicable to this workflow-only change.

Risk & compatibility

This remains a draft. Scheduled creation is opt-in: set repository variable EXT_REQ_BACKPORT_ENABLED=true only after approval. This PR does not enable it or change repository/App/environment settings. Manual runs publish even when scheduled creation is disabled.

Configuration reuses the extensibility-agent environment, EXTENSIBILITY_CLIENT_ID, and EXTENSIBILITY_TRIAGE_APP_PRIVATE_KEY. The App installation needs Contents, Issues, and Pull requests write access to BCApps. Optional EXT_REQ_BACKPORT_TARGET_BRANCH pins an existing releases/<number>.x.

The content boundary is regular, non-executable files under src/, at most 250 changed paths per source. Workflow/build changes, symlinks, and unsafe paths stop before publication. BCApps permits squash merges only; sources must be single-parent commits on main. Hooks, filters, and source content are never executed. Release CI and developer review remain mandatory; the workflow never merges backport PRs.

Sources missed for more than 15 days need a manual single-PR run. Conflicts are tracked, not resolved automatically. A separate human-created conflict-resolution PR is not adopted automatically. An uncertain PR create with no discoverable corresponding object retains its journal intent and requires operator review. Uncertain Task/comment creation must also be inspected before rerunning: without temporary source labels there is no separate durable creation reservation, and object lookup cannot prove an unobserved create did not occur. Oversized complete tables/journals fail explicitly instead of truncating history or creating extra tracking issues. Missing, ambiguous or closed milestones stop publication rather than guessing a different version.

See .github/scripts/bc-extrequest-backport/README.md for configuration, publishing commands, the single source label, and recovery.

[github-advanced-security]

PSScriptAnalyzer found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.

[Marko Aleksandric (AleksandricMarko)]

Manual publication test for #11046 completed using Marko Aleksandric (@AleksandricMarko)'s credentials, with the workflow's existing preparation and body/label templates. This was not a GitHub App-backed workflow run.

• Tracking Task: [Backport 29.x] #11046: [Extensibility Request] issue 10889: expose large text modal helper #13110.
• Draft backport PR: [Backport 29.x] #11046: [Extensibility Request] issue 10889: expose large text modal helper #13111, targeting releases/29.x.
• Cherry-pick changes only QltyEditLargeText.Page.al: makes RunModalWith public.
• The original PR received only ext-backport-processed; original issue [Quality Management] Make internal procedure RunModalWith public on page 20441 Qlty. Edit Large Text". #10889 retained its body, labels and closed state.

The live test exposed two integration issues to address before enabling the workflow:

1. Existing Team Ownership Classification automation replaced the tracking Task's inherited Team: SCM with Team: Other and added Ownership: Needs Review. Issue events confirm those changes were made by github-actions[bot].
2. For Microsoft: Validate link to internal work items rejects the plain tracking-Task hyperlink. Its message requires a GitHub Task reference using Fixes #<number> (or an ADO work item). The new Task has the correct Task type, but the generated neutral link is insufficient.

No workflow code, bot-authorship checks, environment protections or scheduling settings were changed for this manual test. Future App-authored publication remains untested; personally authored tracking objects are not automatically adopted by the App-only publisher.