Webhooks branch filtering

Just a feature that I'd find useful: I have a web hook that is triggered on Push events, however I only want it to be triggered for pushes to a specific branch(s). When creating a webhook, it could be possible to select the branches where the webhook would be triggered.

Perhaps even having some kind of regex matching so that for instance, all branches following feature/* would trigger a certain webhook.

I have found gitlabhq/gitlabhq/issues/1176, but there was no answer at the time.

Thanks,

Added feature proposal webhooks labels

yes. this is absolutely needed feature. especially for CI/CD systems, that start deploy on webhook. any change in any branch triggers redeploy because there is no possibility to set a hook only for master push. very annoying (

Any progress on this? According to https://github.com/gitlabhq/gitlabhq/issues/1176 this is affecting quite a few users...

+1

+1

I've labelled this as Platform, but might be ~CI related? (https://gitlab.com/gitlab-org/gitlab-ce/issues/20338#note_17148232)

added ~480950 label

changed milestone to %Backlog

Yes this would be very useful! +1

Yes definitely needed +1

+1

+1

+1

added ~123454 label

+1

/cc @mydigitalself

mentioned in issue #17457 (moved)

added shortlist label

+1

Being able to set webhooks to branches is important for our automated deployments....we were investigating complicated work arounds until I saw this as a request.

+1

What would it look like in the UI?
Would it be similar to the protected branches UI with wildcards?

/cc @tauriedavis, @dimitrieh

added ~19492 label

Issues that need UX should not be labeled with Accepting Merge Requests so I've removed this.

cc @mydigitalself for possible scheduling.

removed ~123454 label

+1

+1

+1

+1

Please please please escalate this. Larger scale projects become too noisy without branch filtering. +1

Pls, it's 2017.

+1

+1

cc @dimitrieh @markpundsack @mydigitalself Largely asked for feature. Lets get this started so we can add it to an upcoming release.

We need to do some pretty significant overhauling of our integrations & hooks. I absolutely want to do this in the future, but it would probably be a little later in the year, but it's certainly on my shortlist to schedule. We have a lot of performance-related work and some EE related work in priority right now, but will certainly look at this in the summer.

mentioned in issue #32925 (closed)

Maybe this is the correct feature or maybe there is some intermediate work around.

I'm looking for 2 possible webhook/trigger/something.

1. Push to X branch -> Run Pipeline (.gitlab-ci.yml already doing this) -> Open MR for X branch to Y branch (in some cases this is master, in some cases this is dev) -> Run Pipeline (.gitlab-ci.yml already doing this upon commit) -> Merge if Pipeline succeeds -> Close MR -> Possibly Delete branch (since the functionality is based on the X branch if it needs to remain that can be done).

or

2. Push to X branch -> Run Pipeline -> Open MR -> Run Pipeline -> (manually accept MR if build succeeds)

+1

+1

+1

+1

+1

+1

+1

+1

+1

@markglenfletcher would you be able to provide some insight here? I know we briefly discussed in #14646 (moved)

changed milestone to %Next 2-3 months

+1 i think is the right moment resovl this

is a great missing feature. Now for every push in every branch, the pipeline is triggered.

Maybe we can squeeze this into 10.1 @mydigitalself?

moved to gitlab#5592

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