Ado Pr Publish Flow

Ado Pr Publish Flow

Overview

Publish the current branch to Azure DevOps with consistent naming, linking, and conflict handling rules. Complete the flow in one pass: commit, push, check conflicts against origin/dev, resolve if needed, create PR, and return the PR URL. Run git history-changing steps sequentially, never in parallel (especially commit and push).

Workflow

1) Collect context and normalize work item IDs

1. Read current branch: git rev-parse --abbrev-ref HEAD.
2. Resolve Azure DevOps defaults if needed:
   • az devops configure --defaults organization=https://dev.azure.com/TCMD project=Andromeda
3. Determine in-scope AB IDs from user input first.
4. If IDs are not explicitly provided, infer from:
   • Branch pattern users/andreym/<id>-...
   • Existing commit text containing AB#<id>
5. Fetch each ID with relations:
   • az boards work-item show --id <id> --expand relations -o json
6. Build two ID sets:
   • Commit link IDs: all in-scope IDs.
   • PR link IDs: all provided/in-scope IDs, plus parent IDs for any provided child item.

2) Enforce branch naming convention

1. Required pattern for features/bugs:
   • users/andreym/{ticketNumber}-some-short-explanation
   • Example: users/andreym/1111-localization
2. If creating a new branch for a ticket, base it on latest origin/dev:
   • git fetch origin dev
   • git switch -c users/andreym/<firstId>-<short-slug> origin/dev
3. If the current branch does not match and you have at least one AB ID, create a compliant branch from the current HEAD only when explicitly continuing pre-existing work.
4. If the current branch already matches, keep using it.

3) Commit and push all current changes

1. Stage all current changes:
   • git add -A
2. Generate a concise commit subject from the diff:
   • Base on changed files and the dominant intent.
   • Keep the subject short and specific.
3. Ensure the commit message includes AB linking with Fixes AB#....
4. Use this format:
   • Subject: <TicketType> #<id>[ #<id>...]: <short change summary>
   • Body/footer: Fixes AB#<id> AB#<id> ...
5. Normalize <TicketType> for commit subjects to Infra/Feature/Bug (never Task) using the same mapping rules as PR titles.
6. Push (sequentially after commit; do not run in parallel with commit):
   • git push -u origin <current-branch>
7. Verify push propagated to remote before creating PR:
   • git fetch origin
   • git rev-parse HEAD
   • git rev-parse origin/<current-branch>
   • If SHAs differ, push again and re-check.

4) Check conflict risk against latest origin/dev

1. Fetch latest target branch:
   • git fetch origin dev
2. Detect conflict risk without modifying history:
   • BASE=$(git merge-base HEAD origin/dev)
   • git merge-tree "$BASE" HEAD origin/dev | rg '<<<<<<<|>>>>>>>'
3. If no conflict markers are found, continue to PR creation.
4. If conflict markers are found:
   • Merge latest dev into current branch: git merge origin/dev
   • Resolve conflicts in files.
   • Stage resolved files: git add <resolved-files>
   • Commit conflict resolution with AB linking:
     • Subject: Infra #<id>[ #<id>...]: Resolve merge conflicts with dev
     • Body/footer: Fixes AB#<id> AB#<id> ...
   • Push updated branch again.

4.5) Validate PR branch contains only intended commits

1. Inspect divergence from target:
   • git log --oneline --left-right origin/dev...HEAD
2. Confirm commits on the > side are in scope for the current ticket(s).
3. If unrelated commits are present:
   • Rebase/cherry-pick onto latest origin/dev.
   • Prefer git rebase --onto origin/dev <old-base> <current-branch> when linear cleanup is straightforward.
   • Otherwise create a clean branch from origin/dev, cherry-pick intended commits, then force-push with lease:
     • git push --force-with-lease origin <current-branch>

5) Build PR title and description with naming/linking rules

1. Use PR title format:
   • {ticket type} #{ticket number}: {name of story}
2. Ticket type rules:
   • PR titles may only use: Infra, Feature, Bug (never Task).
   • Use type from Azure Boards when available, then normalize to one of: Infra, Feature, Bug.
   • If Azure Boards returns Task, resolve the parent work item type and use it when it maps to Infra/Feature/Bug.
   • If parent type is missing or still not mappable, default PR title type to Feature.
3. Ticket number rules:
   • Include all provided work item ticket numbers.
   • Do not include parent-only ticket numbers in the PR title.
   • Multiple numbers format example: Bug #1234 #5678: Fix login crash
4. Story name rule:
   • Use the primary story/work item title or a short meaningful explanation.
5. PR description must be Markdown and include:
   • What changed
   • Why it changed
   • How it was validated
   • Links section with Fixes AB#...
6. PR link policy:
   • In commit(s): include Fixes AB#... for all in-scope IDs.
   • In PR: include all provided item IDs in Fixes AB#....
   • If a provided item has a parent, include that parent ID too.
   • Parent IDs are linked as PR work items only and are not added to the PR title.

6) Create PR with Azure CLI

1. Write PR description to a markdown file (for example pr.md).
2. Create the PR to dev:
   • az repos pr create --repository Andromeda.iOS --source-branch <current-branch> --target-branch dev --title "<title>" --description @pr.md --work-items <pr-link-ids> --delete-source-branch true
3. Return the PR URL from command output.
4. Remove temporary pr.md after PR creation.

Output requirements

1. Report:
   • Current branch used
   • Commit(s) created
   • Whether conflicts were detected/resolved
   • Final PR title
   • Final PR URL
2. If required metadata is missing (for example no AB ID), fail fast and state what is missing.
3. Never skip naming or linking conventions.