<!-- This issue template can be used as a great starting point for feature requests. The section "Release notes" can be used as a summary of the feature and is also required if you want to have your release post blog MR auto generated using the release post item generator: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator. The remaining sections are the backbone for every feature in GitLab. The goal of this template is brevity for quick/smaller iterations. For a more thorough list of considerations for larger features or feature sets, you can leverage the detailed [feature proposal](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md). --> ### Workaround https://youtu.be/1u5c2PzQ9fs ### Release notes <!-- What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). " --> ### Problem to solve Developers often start an MR early in feature development to make it easier to collaborate on the proposed implementation. It doesn't make sense to run costly tests and the full pipeline for Draft MR commits. The common workflow is as follows: 1. work in branch with opened MR in a draft state (detached pipelines will be created) 1. after work is done - resolve draft status (mark the MR as read in the UI or by changing the description) `this is when the merged results pipeline should be created` 1. merge after pipeline for merged result succeeded Developers would like to have a pipeline automatically created when the draft MR is marked as ready. Reason for that - code for detached pipelines may differ from merged requests pipelines, so developers need to re-run tests on it before allowing MR to be merged. <!-- What is the user problem you are trying to solve with this issue? --> #### Further details :point_up: We have a new feature POC that would address the problem in this issue, so the work on this issue has been paused to see if we can address it with the following: > we would get this feature working "for free" and out-of-the box if we ship GitLab CI Workflows. I have my PoC ready here: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/91244. See demo: https://youtu.be/cwfRI9m3rRs ### WIP Proposal - If the pipelines running in `DRAFT` state are different from the pipelines running for a `READY` MR, automatically create a new pipeline when an MR changes state from `DRAFT` to `READY`. | Mark MR as "ready" | | ------ | |   | #### Further details <details><summary>Implementation details</summary> WIP events are handled by: - https://gitlab.com/gitlab-org/gitlab/-/blob/c7bfa18f7b6f60d79d93f6c5423f27d20e701df3/app/controllers/projects/merge_requests_controller.rb#L248-254 - https://gitlab.com/gitlab-org/gitlab/-/blob/c7bfa18f7b6f60d79d93f6c5423f27d20e701df3/app/services/merge_requests/update_service.rb - https://gitlab.com/gitlab-org/gitlab/-/blob/c7bfa18f7b6f60d79d93f6c5423f27d20e701df3/app/services/merge_requests/base_service.rb#L75-79 - https://gitlab.com/gitlab-org/gitlab/-/blob/c7bfa18f7b6f60d79d93f6c5423f27d20e701df3/app/services/issuable_base_service.rb#L187 - https://gitlab.com/gitlab-org/gitlab/-/blob/c7bfa18f7b6f60d79d93f6c5423f27d20e701df3/app/services/merge_requests/update_service.rb#L128-142 - https://gitlab.com/gitlab-org/gitlab/-/blob/c7bfa18f7b6f60d79d93f6c5423f27d20e701df3/app/services/merge_requests/base_service.rb#L81-85 - https://gitlab.com/gitlab-org/gitlab/-/blob/c7bfa18f7b6f60d79d93f6c5423f27d20e701df3/app/services/merge_requests/base_service.rb#L87-96 Somewhere along this call chain we should introduce a call to [`MergeRequests::CreatePipelineService`](https://gitlab.com/gitlab-org/gitlab/-/blob/c7bfa18f7b6f60d79d93f6c5423f27d20e701df3/app/services/merge_requests/create_pipeline_service.rb) </details> <!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. --> ### Intended users * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) <!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ * [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#cameron-compliance-manager) * [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager) * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Presley (Product Designer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#presley-product-designer) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Priyanka (Platform Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#priyanka-platform-engineer) * [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator) * [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst) * [Rachel (Release Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#rachel-release-manager) * [Alex (Security Operations Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#alex-security-operations-engineer) * [Simone (Software Engineer in Test)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#simone-software-engineer-in-test) * [Allison (Application Ops)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#allison-application-ops) * [Ingrid (Infrastructure Operator)](https://about.gitlab.com/handbook/product/personas/#ingrid-infrastructure-operator) * [Dakota (Application Development Director)](https://about.gitlab.com/handbook/product/personas/#dakota-application-development-director) * [Dana (Data Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#dana-data-analyst) * [Eddie (Content Editor)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#eddie-content-editor) --> ### Feature Usage Metrics <!-- How are you going to track usage of this feature? Think about user behavior and their interaction with the product. What indicates someone is getting value from it? Create tracking issue using the Snowplow event tracking template. See https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Snowplow%20event%20tracking.md --> <!-- Label reminders Use the following resources to find the appropriate labels: - https://gitlab.com/gitlab-org/gitlab/-/labels - https://about.gitlab.com/handbook/product/categories/features/ --> <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->