Trigger_parameters.webhook.body for WebHook and parameter for manual triggering at the same time

Build Environment
1

Hi!

I want a workflow to be startable both manually via GUI and via a custom webhook. In both cases I need to pass down a parameter.

So, I tried adding a condition to my workflow like

my_workflow:
when:
      or:
        - equal: [e2e, << pipeline.parameters.manual_trigger_value >>]
        - equal: [e2e, << pipeline.trigger_parameters.webhook.body >>]

But when starting this manually, it complains Error calling workflow: 'my_workflow' Unknown variable(s): pipeline.trigger_parameters.webhook.body

How do I solve that?

What I tried:

Defining trigger_parameters in the head of my CircleCI config file like I do for parameters. Did not work.

1 Like
2

Hi @cis thanks for raising this.

Can you tell me more about your use case for using a custom webhook here?
Currently there is no way to pass custom parameters (those declared at the top of your config file) via custom webhook, because typically custom webhooks are emitted from third party system, and more often than not you wouldn’t have control over the payload.
I wonder if perhaps using an API call instead of a custom webhook would work for what you’re trying to do?

Let me know!

3

Thanks for your answer. The use case is that I want to be able to trigger a pipeline by calling a single route and be able to share the URL and payload with the rest of the department. As far as I see, for webhooks you get a secret which can only trigger that very pipeline. That’s okay to share security-wise in my opinion. Whereas an API call would include my personal API token - which is far too powerful to share with anyone.

And the problem is not that manual_trigger_value would be undefined via a webhook call. That’s obvious. The problem is the other way round: pipeline.trigger_parameters.webhook.body is not defined when calling the pipeline not from webhook - as you can see in the included error message.
So, how do I “tell” CircleCI: “If you get here and pipeline.trigger_parameters.webhook.body is undefined because not a webhook context, then treat pipeline.trigger_parameters.webhook.body just as an empty string”?

4

I see, thanks for all the clarification, this context helps a lot.

pipeline.trigger_parameters.webhook.body is indeed supposed to be an empty string here - this is an issue on our side. We should be able to fix it in the next week or two, I can let you know as soon as the fix goes live.

In the meantime, if you’re looking for an immediate solution, you could create a near-identical copy of your .yml file that doesn’t include the check on webhook.body, and create a new pipeline that points to the new file.
Then you’d use the UI to trigger this new pipeline, while keeping your Custom Webhook trigger pointing to your original pipeline.

Let me know if this helps!

2 Likes
5

Hi @cis , just wanted to let you know that we’ve just shipped a fix for this. pipeline.trigger_parameters.webhook.body now has a value of {} for all pipelines that are not triggered via custom webhook.
Could you confirm that this allows you to achieve what you need?

6

Hi @Benny I am trying to setup a workflow in the exact same way as @cis, but as soon as I push the branch with the new config, I get the same error:
Unknown variable(s): pipeline.trigger_parameters.webhook.body

Should this be fixed by now?

7

@malunem

The issue is that at the moment the parameter webhook.body is not yet populated for pipelines that are triggered via our GH OAuth App integration (you can see those in your Project Settings > Pipelines). We plan on fixing this, but it’s a a bit more complex to do so won’t be able to do this quickly enough to unblock you I’m afraid.

I think @Benny responded to your email with some other workarounds. Let her know if those don’t work. For others on this thread, the workarounds involve creating a separate YML configuration file (or multiple of those) in addition to the config.yml. You would leave config.yml for your normal pushes to your repo and have your other pipelines with their configuration files handle other units of work that you need to accomplish.