Trigger a build for a merge request after `wip` prefix is removed from merge request title

Description

GUI, browser automation tests are expensive and take a long time to run. As a developer, I want to be selective when these tests should run.

Proposal

As a developer I would like to trigger a build for a merge request when I remove wip prefix from the merge request title.

@dainius Thanks for your feedback and proposal. It makes sense. To clarify, so your workflow is to use WIP Merge Requests until the feature is complete (and to prevent automated builds for your new pushes) and when removing the WIP flag you'd like the automated builds to commence?

added ~19173 feature proposal ~13921 labels

@markglenfletcher exactly and thanks for the reply. We would like to keep this trigger inside of gitlab (using Jira webhooks on transitions is an alternative) I can imagine this to be an addition to the current set of webhooks.
note: we are using gitlab ee, but I believe such trigger would be useful for a wider public too.

@rymai What do you think about this proposal?

@dainius @markglenfletcher I don't know, I think that WIP shouldn't mean no CI. In fact, I know some developers that like to have all their commits to be green, even when the merge request is still in a WIP state. /cc @grzesiek

One thing you could already do is to include [ci skip] in your commit to skip the CI builds.

I think this might be a good reason to use optional manual actions. You would simply need to click a manual action to execute builds. This feature might need some refinement, but we also plan to execute a test job for full QA integration tests only before the merge. I'm still not sure what would be the best approach to achieve that. I have a gut feeling that we might need https://gitlab.com/gitlab-org/gitlab-ce/issues/23902, making a merge request a first-class citizen in .gitlab-ci.yml and building similar future on top of that, but this concept still requires some product work. What do you think @joshlambert?

Thanks @dainius for the submission. I tend to agree this may be a good use of manual actions, for now. CI operates primarily on branches right now, and not MR's to your point @grzesiek. So I'd rather make specific MR based features part of (or on top of) #23902 (moved). I think this will keep things cleaner and more logical.

@markglenfletcher @rymai @grzesiek @joshlambert

Thank you all for input.

I am nicely surprised that this ticket was picked up so quickly and sparked a discussion.

Options discussed:

1. [ci skip]

This option implies commiting only for triggering tests. In my opinion, commits should be used to alter the state of the codebase, but not configure continuous integration.

2. Manual Actions

The concern with Manual Actions is that it requires an action solely for the purpose of triggering tests. This increases the number of steps in our workflow, which we would like to minimize. In addition, this step can be forgotten.

3. #23902 (moved)

We create a new pipeline when a new merge request is opened,
We create a new pipeline for every merge request that gets updated by push,

In both cases the trigger would be too often.

Background:

I believe I should have provided this information in the initial request. There should be no feature requests without why.

We run unit tests on each push. Its great because it is fast. Its true.

Feature tests (cucumber/watir) takes 70min to run and is growing. We cant execute them on every commit and there is not really a need for it. Running them once before merging seems to be sufficient.

Our application consists of three gitlab projects - one backend and two frontends. A script starts servers on branches where code was changed, otherwise default to master. Branch names across projects has a common identifier which is a ticket number.

Currently we need have to have a pipeline for each project as we cant share the state of it across the projects.

I imagine a job run only on triggers defined in .gitlab-ci.yml

The issue is when to fire up the script to start the tests.

Why webhook on removing wip?

• 'wip' already provides a visual cue for the state of the merge request
• it disables the Accept button as we dont want the tests to be merged
• it seems like a good time to start expensive system tests, since work on the branch is done

This feature request focuses on wip prefix, but the underlying idea is to have more control on when to start tests, whilst streamlining the workflow and keeping our devs happy. On a sidenote, I imagine webhooks for adding/removing labels being helpful too.

mentioned in issue #14174 (moved)

moved to gitlab#8151

Hey!

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

You can also find more information here:

• https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
• https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue