<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=31543) </details> <!--IssueSummary end--> ### Problem to solve When working on Gitlab CI/CD, it is often necessary to create test commits to see how the pipeline will run. These commits clutter up the history with commits which are not useful to roll-back to, as they are experiments rather than developments. The same difficulty arises when using the WebIDE to work on any code in a project which requires going through the CI/CD pipeline to test the work done. ### Intended users DevOps Engineers, Developers ### Further details Example situation: * Add a new job to the .gitlab-ci.yml via the WebIDE * Run .gitlab-ci.yml through CI-linter to check syntax errors * With no syntax errors, commit changes to run pipeline * Pipeline fails * Commit new changes to fix mistakes * Repeat until pipeline succeeds Re-basing/squasing would clean the history, but this may not be compatible with a team's merging policy. ### Proposal Add a way to run a pipeline on staged changes in the WebIDE, before commiting. To facilitate this, create a temporary commit for testing, but do not add it to the WebIDE's target branch. Since pipelines operate using information about the branch, it may be best to create a temporary branch for testing as well: treat this testing as a merge-request into the target branch. ### Permissions and Security The same permissions are are required to commit and run a pipeline on the (eventual) target branch. ### 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 Ensure that test commits do not affect the target branch. ### 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. --> ### Links / references https://gitlab.com/gitlab-org/gitlab-ce/issues/58606