Setting variables when deploying a project via the API

Is there a way to trigger this “variables” functionality when deploying a project via the API?
When a parent project deploys a child using the Deploy a Release step documented above and you set a variable it overrides the variable in the child project if it exists.
Using the POST /deployments endpoint allows setting prompted variable values with the FormValues but this seems to only work for prompted vars, not general project variables.

Hi Shaun,

Thanks for getting in touch and for the great question. You’re correct in that when creating a deployment, at that point only prompted variables can have values set to them at that point in time. Project variables are snapshotted into the release when its created.

What I think you might be able to do to here is still use prompted variables, but bind the prompted variable to this value that will be passed in to the child project’s deployment. In the screenshot from our doc page pasted below, that would mean replacing Princess Allura with #{YourPromptedVarName}.

Then set the value for this prompted var when creating the deployment of this parent project, which will evaluate there and pass in the value set via the FormValues.

Let me know what you think, or if you have any questions at all!

Best regards,


Thanks Kenny,

I was hoping you would tell me about the undocumented API that feature was using :wink:

That at least clears up that it’s not trivial with the existing public APIs.

My primary use for passing variables to child deployments is just to tell the child that it is part of an orchestrated deploy so it can skip some steps e.g. I want the parent to flush some caches or restart services not for every child deployment to try and do this. It works using the step we were talking about but I have a runbook that deploys projects dynamically from a powershell which is where I was trying to do this.

Hi Shaun,

Thank you for following up! I’m curious if you could simply have a project variable in the child project (in my example, it is called Orchestrated, set to False), then on your Deploy a Release step, pass in an identically named variable with value of True. Since it overrides a project variable if it exists, that should then evaluate to True when the parent project kicks off the deployment, but False if not. This sounds like what you might have already tried, so I’m wondering if that itself isn’t working as expected?

Since the variable being passed into the child is defined on the Deploy a Release step in the parent itself, that means it will be hardcoded into the release snapshot of the parent project. I don’t believe prompted variables will in fact be required to automate the functionality of skipping some steps in the child if it is orchestrated via the parent project, if I am understanding what you’re after correctly.

Using the same example above, I’m imagining you could pass in the variable with name Orchestrated with value of True (which will override False) in the Deploy a Release step itself, then set the run condition on the applicable steps in your child project to something like #{if Orchestrated}False#{/if}.

There’s a good chance I’m misunderstanding some key piece of your goal here, so please let me know if so. :slight_smile:

Best regards,


This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.