gitlab-plugin icon indicating copy to clipboard operation
gitlab-plugin copied to clipboard

Add the ability to parse the whole webhook JSON payload

Open omehegan opened this issue 8 years ago • 14 comments

Right now when the plugin receives a webhook JSON payload, we parse it and, if the project type is not Pipeline Multibranch, we set various environment variables using some of the JSON data, and discard the rest. Every few months a user asks us to add another env var from something in the JSON.

The plugin pre-dates Pipeline, and originally was really just intended to receive the relevant branch name from the webhook, and use that when cloning the repo. GitLab and Jenkins have come a long way since then. I have thought for awhile that, at least for Pipeline jobs, it would make everyone's life simpler if we just slurped the whole JSON payload into a Groovy data structure. Then anyone using Pipeline could access any of the data in the payload, and when GitLab adds things to it they would automatically be available.

omehegan avatar Jan 30 '18 01:01 omehegan

@omehegan would you please give some advice to workaround or fix this problem. We really need to merge branches before build in multibranch pipeline. At this moment i'm trying to create rails application, accepting copy of webhook from gitlab and transport it into the pipeline workspace. And this crutch makes me cry.

rubycrafter avatar Mar 01 '18 12:03 rubycrafter

@rubycrafter I don't know of a workaround unfortunately. You should be able to merge before build on e.g. Pipeline job types - those should receive enough of the necessary JSON parameters to be able to do that. So maybe you could put something together using a regular Pipeline job which then triggers a Multibranch job (if that's even necessary at that point).

omehegan avatar Mar 23 '18 05:03 omehegan

@rubycrafter also what you are asking for is more directly related to #704.

omehegan avatar Mar 23 '18 06:03 omehegan

This feature is what Generic Webhook Trigger does. @rubycrafter

tomasbjerre avatar Nov 12 '18 19:11 tomasbjerre

Is there any planned work on this issue soon?

byahia avatar Mar 12 '19 16:03 byahia

It would be really cool if the whole "source payload" could be provided through the plugin, particularly merge request's creation & modification dates.

Have you planned to work on this feature any time soon?

denis-colliot avatar Jul 12 '19 14:07 denis-colliot

It seems like it would be very easy to just provide the whole payload. Is there any plan to get this done?

atrifex avatar Aug 01 '19 17:08 atrifex

Any Plans to make the whole payload available in some variable or something. I have a requirement to parse for the module names in a multi-module project.

However being unable to access the entire payload, have to use some other plug-in :'(

JyotirmoyVS avatar Aug 08 '19 10:08 JyotirmoyVS

I would also need this feature. Any plans on this?

heppu avatar Oct 24 '19 12:10 heppu

Any Update on this issue. Is there anyway to get lables out of it atleast

siyas13 avatar Nov 26 '19 10:11 siyas13

Is there a hacky/unsafe way to import the plugin classes into the pipeline script to get the raw data from the JSON payload?

I'd settle for that, otherwise I might need to use the generic webhook plugin.

angelichorsey avatar Feb 27 '20 23:02 angelichorsey

Any updates on this issue ?

elkh510 avatar Oct 26 '20 16:10 elkh510

Any updates on this issue ?

teragoon avatar Apr 02 '21 08:04 teragoon

Even though we could parse the json through the generic webhook, it would be very handy to have something out of the box with the gitlab-plugin, specifically for MRs

ntmggr avatar May 26 '22 15:05 ntmggr