darwin-mr-lifecycle

name	darwin-mr-lifecycle
description	MR/PR lifecycle operations -- pipeline check, retest, merge, conflict reporting. Extends darwin-gitlab-ops.
requires	["darwin-gitlab-ops","darwin-pipelines-as-code"]
roles	["developer","sysadmin"]

MR/PR Lifecycle Operations

Handles the full MR/PR lifecycle: check pipeline, retest, merge, and conflict reporting.

CRITICAL: For the project path and MR/PR URL, always use the values from the event document's GitLab Context section.

Use the service tools only for aligner events or when a user asked

Fixing Pipeline Failures on an MR

Before modifying an MR's source branch, read the MR description for Bot Instructions (### Bot Instructions section). If instructions restrict modifications, report the constraint to FRIDAY instead of pushing. Even when no Bot Instructions are present, the source mutation approval gate still applies — report the proposed fix to FRIDAY and let FRIDAY authorize the push.

When the pipeline failure requires a code/config fix (e.g., Dockerfile update, dependency bump):

• Before modifying the branch, check whether auto-merge is active on the MR/PR. If active, disable it BEFORE pushing your commit. A push to a branch with auto-merge enabled will merge to main on pipeline success, bypassing human review of your code changes. Report the auto-merge status in your response to FRIDAY.
• Checkout the MR's source branch -- NEVER push fixes to main directly.
• Apply the fix, commit, and push to the remote source branch only after FRIDAY approval.
• The MR/PR pipeline retriggers automatically on the push.
• If the MR/PR was created by a bot (Kargo, submodule updater), you still fix on the MR's source branch.
• The purpose of MR/PR pipelines is to validate changes BEFORE main. Merging untested fixes to main defeats this.

Retest Pipeline

To trigger a pipeline retest, post the appropriate PaC GitOps command as an MR/PR comment. See the darwin-pipelines-as-code skill for command selection (e.g., /retest for transient failures, /test for full re-trigger).

After posting, check pipeline status to confirm the retest was accepted.

Pipeline Timing

After retesting:

1. Check pipeline status immediately. If running or pending:
   • Report back with current state. FRIDAY will defer and re-dispatch you later.
   • On subsequent dispatches, if the pipeline is still non-terminal, check queue state on the build cluster (see darwin-k8s-mcp) and include it in the report.
2. If success: proceed to merge.
3. If failed: read the failed job log and report the error.

Do NOT poll in a loop -- report the current state and let FRIDAY handle the timing.

Merge MR

Before merging, perform these pre-merge checks IN ORDER:

1. Agent-authored commits: Check ALL commits between HEAD and the merge base. If ANY commit was authored by a Darwin agent (author email ends with @darwin-project.io), do NOT merge. Report to FRIDAY that the MR/PR contains agent-authored code requiring human review.
2. Pipeline status on HEAD: Verify the latest pipeline ran on the MR's current HEAD commit and its status is success. If the pipeline is from an older commit, or status is pending/running/failed, do NOT merge. Report the state to FRIDAY.
3. CI bot comments: Read the last 5 MR/PR notes. If any CI bot comment contains CAUTION, error, Pending approval, or waiting for /ok-to-test, do NOT merge. Report the CI warning to FRIDAY.
4. Merge status: Confirm merge_status is can_be_merged.

Only merge when ALL checks pass.

Safety Rules

• NEVER force-push to any branch
• NEVER merge with a red/failed pipeline
• NEVER merge when CI is pending approval (waiting for /ok-to-test) or has bot CAUTION warnings
• NEVER merge when the latest pipeline is from a different commit than HEAD
• NEVER auto-rebase -- if merge_status is cannot_be_merged, report conflicts to maintainer
• NEVER delete branches after merge (let GitLab's auto-delete handle it)
• NEVER merge when the MR/PR contains agent-authored commits (author email ends with @darwin-project.io)

Conflict / Unmergeable Handling

If merge_status is cannot_be_merged:

For automated submodule MRs (branch starts with submodule-, author is a bot):

• This means a newer submodule update already merged to main. The MR/PR is obsolete.
• Close the MR/PR with a comment explaining why (a newer submodule update has already been merged).

For all other MRs:

• Post an MR/PR comment describing the conflict (merge conflicts detected, manual rebase required).
• In your response to FRIDAY, recommend sending a Slack notification. FRIDAY owns Slack and knows who to notify -- do NOT include usernames or @mentions in your recommendation.

Critical: No @mentions

Do NOT tag individual users (@username) in MR/PR comments or anywhere else. Do NOT query project/group members to find usernames to tag. MR/PR comments must only describe what happened -- FRIDAY handles all human notifications via Slack.

Reporting Results

Always end your response with a clear recommendation for FRIDAY. Do NOT include GitLab usernames or @mentions -- FRIDAY has its own maintainer list.

• Merged: "MR/PR merged successfully."
• Retest triggered (non-terminal): "Retest triggered, pipeline is running/pending. Pipeline outcome is not yet known."
• Pipeline running: "Pipeline triggered, currently running."
• Failure: "Pipeline still failing after retry. Recommend notifying maintainer with failure details."
• Merge blocked by CI: "Cannot merge — CI bot reported warnings or pipeline has not run on HEAD. Details: {summary of CI comments}."
• Conflict (submodule): "Closed obsolete submodule MR/PR -- newer update already merged to main."
• Conflict (other): "Merge conflicts detected. Recommend notifying maintainer to rebase."
• Agent code detected: "MR/PR contains Darwin-authored commits. Requires human approval before merge. Recommend notifying maintainer."