Queries on Webhook

[Manikkumar K]

How do we know the status of the web hook, for example, Say Im firing more than one web hook to trigger a pipeline, is there a way we can query the queue status & pipeline instance of the web hook(s) it has picked up?

Second query is above, if we would fire more than one web hook to a same pipeline, would go server aggregate all into one singe instance? Or is it like 1-1 mapping where each web hook corresponds to one pipeline instance?

[Chad Wilson]

I'm not sure I understand the question or what you are trying to achieve, however.....

Webhooks notify the GoCD server of a change to materials. The GoCD server then finds the relevant material(s), and updates them from source to determine the changes. It then follows normal operations (as it would with polling) to determine which pipelines are affected by the changes to the material (there may be one or more pipelines linked to a given material, denylists/whitelists to consider, plugins to ask etc).

In some sense it sounds like you are thinking about this in slightly the wrong way. In GoCD materials are a top level concept which manage incoming triggers to pipelines. So you don't trigger a pipeline, you trigger a "check" on a material. Pipelines see "stage triggered due to change in material", not "pipeline triggered by webhook".

https://www.gocd.org/getting-started/part-1/#concept2

As to whether webhook events are "batched", I don't believe they are in any deterministic way. If pipeline A has input materials X and material Y, and there are 2 webhook events that trigger an update to both X and Y, you may or may not get two pipeline runs - similar to what might happen if the server was polling the materials in "normal" operation. I'm personally not sure if it's 1:1 or not in the case of webhook-triggered material updates, but speaking generally I doubt GoCD gives this guarantee. e.g if a pipeline's stage1 is already running, and then two webhooks are fired that affect that pipeline's materials, I would guess that they would end up batched into one pipeline instance when stage1 next triggers.

As to "status", I don't think the material subsystem exposes any particular status to know what it is doing, how it is responding to webhook changes etc. Probably you could enable some debug logging if trying to diagnose a particular problem, but don't have the relevant config to hand.

-Chad

On Thu, Jun 15, 2023 at 9:55 AM Manikkumar K <manikk...@thoughtworks.com> wrote:

How do we know the status of the web hook, for example, Say Im firing more than one web hook to trigger a pipeline, is there a way we can query the queue status & pipeline instance of the web hook(s) it has picked up?

Second query is above, if we would fire more than one web hook to a same pipeline, would go server aggregate all into one singe instance? Or is it like 1-1 mapping where each web hook corresponds to one pipeline instance?

--
You received this message because you are subscribed to the Google Groups "go-cd" group.
To unsubscribe from this group and stop receiving emails from it, send an email to go-cd+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/98459935-967a-4c15-8a27-0d6afbe5fe72n%40googlegroups.com.

[Aravind SV]

On Thu, 15 Jun 2023 at 03:15, Chad Wilson <ch...@thoughtworks.com> wrote:

I'm personally not sure if it's 1:1 or not in the case of webhook-triggered material updates, but speaking generally I doubt GoCD gives this guarantee. e.g if a pipeline's stage1 is already running, and then two webhooks are fired that affect that pipeline's materials, I would guess that they would end up batched into one pipeline instance when stage1 next triggers.

That’s correct. They will get batched. The next run will see commits from both those triggers.

It’s just a normal material update check to GoCD.  

Cheers,

Aravind