### Problem to solve <!-- What problem do we solve? --> It is time-consuming to activate multiple manual actions for a single stage within a pipeline. <details> <summary>Original user story</summary> I have a pipeline that contains multiple manual jobs:  If I want to start all of them I need to click the "play" button on each item and ~~get redirected to the jobs page for each~~ (got fixed with https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18185). So I need to go back for the next button to click. This is very time-consuming. </details> ### Intended users <!-- 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 can be found at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ --> ~"Persona: DevOps Engineer" ### Further details <!-- Include use cases, benefits, and/or goals (contributes to our vision?) --> This will contribute towards making verify pipeline pages loveable ### Solution <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> #### User stories | # | User Story | Persona | Scope | | ------ | ------ | ------ | ------- | | 1 | As an engineer, I want to be able to more easily start all manual jobs within a single pipeline stage | ~"Persona: DevOps Engineer" | Current | | 2 | As an engineer, I want to be able to more easily stop all manual jobs within a single pipeline stage | ~"Persona: DevOps Engineer" | Next iteration #60129 | ##### Technical user stories | # | User Story | Scope | | ------ | ------ | ------ | | 1 | As a designer, I want to create a better information hierarchy to support this feature | Next iteration #54331 | | 1 | As a product manager, I want to keep this as minimal as possible, thus keeping this effort separate from #54331 | Current | #### Acceptance criteria 1. For each stage with manual actions, we will render a play button 1. The button must have a tooltip with `Play all` 1. ~~Once the user clicks play all, we will render a stop button instead (same behavior as each individual jobs)~~ => #60129 1. Once the user clicks play all, each individual job action will be triggered and updated to reflect an updated status (same behavior we have now) - Last 2 points assume backend sends updated endpoints - Clicking the button would schedule all builds in the current stage and reload the page. - The button will not be visible for users without enough permissions ##### User journey ```mermaid graph TD UOP[user opens pipeline page] UCSMAB[User clicks stage manual action button] BBI[Button briefly shows progress indicator] PRS[Page reloads state] AMT[All manual actions within the stage are triggered] BSDS[Button is no longer visible] UOP-->UCSMAB UCSMAB-->BBI BBI-->PRS PRS-->AMT AMT-->BSDS ``` #### Design | Mockup | | ------ | |  | ### Permissions and Security <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)? --> Same permission management functionality as already exists will be functional for this feature. The button will not be visible for users without permission. ### Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements --> ### Testing <!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further guidelines: https://about.gitlab.com/handbook/engineering/quality/guidelines/test-engineering/ --> ### What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> - [ ] Acceptance criteria will be met - [ ] Current user story('s) will be made true - [ ] User journey will be followed success metrics: - [ ] Feature will be tracked, if used X times... ### Links / references #24755 ### Measure Create a capybara script that benchmarks the two solutions in seconds: Clicking one button vs Clicking a button per build.