Add Web hook Trigger that is executed only if a build succeeds

These are the current options for Web hook Triggers:

Push events
This url will be triggered by a push to the repository

Tag push events
This url will be triggered when a new tag is pushed to the repository

Comments
This url will be triggered when someone adds a comment

Issues events
This url will be triggered when an issue is created/updated/merged

Merge Request events
This url will be triggered when a merge request is created/updated/merged

Build events
This url will be triggered when the build status changes

The Build events Trigger is run regardless of whether or not the build is successful.

Can you add an option that will only Trigger the Web hook if the build succeeds?

Thanks!

@SeanPlusPlus the build web hooks have a key called build_status in its payload. If it's set to success (i.e. "build_status":"success") you get the information you want.

I understand that's not the same as a specific trigger for successful builds that could go to another URL, but I doubt that this will happen, because it will just add confusion to the web hooks UI.

You should probably build a trivial script which triggers a downstream web hook only if it receives a gitlab build web hook with the build_status key set to success.

Awesome!

Thx for the updated. I will check this out today.

Added webhooks label

I understand @jkohl idea, but @SeanPlusPlus has a point too.

Adding a variable to the webhook on when to trigger is easier, IMO. If you check whether the status of the trigger (that is, build, pipeline, etc.) is the one you are expecting, before the call, you can reduce misfires and executions of pipelines.

Also, "on status change" is quite ambiguous, and having a fix status or set of them may be better.

@markglenfletcher can we have this as a feature request?

@adin Sure! Thanks for the ping

added ~480950 feature proposal pipeline labels

I just wanted to bring some attention to this feature proposal since the changes that are coming to the CI. With the new cap, triggering pipelines that are already working is a downside. Thus, having a way to control which pipelines are executed and which ones are not is a good way to save execution time.

mentioned in issue gitlab-com/support-forum#1759 (closed)

mentioned in issue #27805 (closed)

@markglenfletcher How was this irrelevant in #27805 (closed)? Job status or Pipeline Status only triggering upon success seems logical.

For example I have .gilab-ci.yml running tests and I only want the webhook to be kicked off if the pipeline passes, because if it fails don't want to run the webhook.

Totally, I am using a web hook to deploy to aws code-pipeline., I dont want to have to change the lambda function that webhooks calls - seems like wrong place to do it. Should be as close to source as possible surely - i.e. in the gitlab webhook config, and only for certain branches.

@cdenneen build_events -> job_events

Anyway you can elaborate as to how to configure this workflow?

@markglenfletcher I'm with @cdenneen on this one. I think that we still need a native way of just triggering successful pipelines, or even better, to trigger on status.

Also, checking the documentation there is not much information on the difference between pipeline and jobs triggers. I guess that a pipeline consists of jobs. Thus, a pipeline is triggered twice(?), and then each job in the pipeline is also triggered, at least, twice too(?).

Can you elaborate?

I'm with @cdenneen. Can you elaborate @markglenfletcher?

mentioned in issue #20338 (moved)

@markglenfletcher I'm sure others are doing something different but what I'd like to accomplish is the following workflow:

• commit to branch 'sync'
• run pipeline
• open MR, automatically merge if build succeeds, delete source branch

So I'm guessing there would need to be a webhook filtered based on branch name 'sync' that would automatically open MR with automatically merge if build succeeds and delete source branch upon push event.

moved to gitlab#4533

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