| 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:
- 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.
- If
success: proceed to merge.
- 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:
- 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.
- 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.
- 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.
- 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."