Writing down a generic MR workflow as a state machine chart.
---
title: MR state chart
---
stateDiagram-v2
direction TB
classDef badBadEvent fill:#f00,color:white,font-weight:bold,stroke-width:2px,stroke:yellow
[*] --> Open
CIFail: Failed pipeline/Conflicts
Success: Success flow
Checks: Checks pipeline
Success --> CIFail
%% CIFail --> Success
%% Success --> Conflicts
%% Conflicts --> Open: Resolving conflicts
%% ^ mermaid issue: bad transition layout. if it points to Success, then transition label will be hidden behind other box
state Success {
Resolved: All comments resolved
Merging: Merge pipeline
%%- Standard path
Open --> Checks
Checks --> Commented
Commented --> Resolved
Commented --> Approved
Resolved --> Approved
Approved --> Merging
Merging --> [*]
%%- Quickest path
Open --> Approved: Quick approve
%%- It depends on project settings, if you have to resolve all comments to merge then true approve comes only after resolving all threads. Then the key action is Resolved, kind of. But approve is required too
%% Commented --> Approved
%% Approved --> Resolved
%% Resolved --> Merging
%% Resolved --> Commented
%%- Key action. Generally, Approved is the action after which you can proceed to Merging
-- Approved
}
state CIFail {
[*] --> [*]
}
%% state Conflicts {
%% [*] --> [*]
%% }
%%- Conflicts
%%- Basically you can go to conflicts from almost every step, because it's non-deterministic, I mean it happens because something MR authors don't control updates in a conflicting way
%% Open --> Conflicts
%% Commented --> Conflicts
%% Resolved --> Conflicts
%% Approved --> Conflicts:::badBadEvent
%% Merging --> Conflicts
%%- Depends on project settings, if you reset approves after push, then you have to go to Open state after Conflicts
%% Conflicts --> Open