Loading
Accept MERGE_REQUEST_LAST_APPROVED_AT and PLAN_STAGE_START stage events
A value stream stage that ends when a merge request is last approved is refused at plan time by gitlab_value_stream_analytics, although GitLab lists it as a stage event. The provider checks start_event_identifier and end_event_identifier against a fixed list, and two events GitLab accepts are not on it.
Changes
- Adds
MERGE_REQUEST_LAST_APPROVED_ATandPLAN_STAGE_STARTto the list. Both are in theValueStreamStageEventenum. The first is listed in the value stream analytics docs as "Merge request last approved". The second is one of the three events specific to GitLab's default stages, and the list already has the other two. Its pairing rule lets it start only a stage that ends onISSUE_FIRST_MENTIONED_IN_COMMIT. - Regenerates
docs/resources/value_stream_analytics.md. - Keeps
MERGE_REQUEST_PLAN_STAGE_START, which the enum does not have, because the support policy holds breaking changes for major releases. Dropping it here is a one-line change.
Tests
TestAcc_GitlabValueStreamAnalytics_ProjectLastApprovedStagecreates a stage fromMERGE_REQUEST_CREATEDtoMERGE_REQUEST_LAST_APPROVED_ATand imports it. Onmainit fails with the validator error. With this change it passes on GitLab.com.- A value stream with both new events applies on GitLab.com, reads back with the same identifiers and plans clean. The configuration is below.
Configuration applied on GitLab.com
resource "gitlab_value_stream_analytics" "probe" {
name = "time-to-approve"
project_full_path = "<group>/<project>"
stages = [
{
name = "Time to approve"
custom = true
hidden = false
start_event_identifier = "MERGE_REQUEST_CREATED"
end_event_identifier = "MERGE_REQUEST_LAST_APPROVED_AT"
},
{
name = "Plan to commit"
custom = true
hidden = false
start_event_identifier = "PLAN_STAGE_START"
end_event_identifier = "ISSUE_FIRST_MENTIONED_IN_COMMIT"
},
]
}An AI coding assistant wrote this change and ran the checks above.
Edited by Andrew Dunn