Any way to acces the parameters that were used to launch a deployment?

Legacy Scale
1

I’m most specifically looking to get the Tenant Tags that were used. This is for launching a related project as the final step of the parent deployment. I tried using Octopus.Deployment.Tenant.Tags, but that gives all tags associated with the tenant currently deploying and that is not specific enough.

2

Hi!

Thanks for getting in touch! The short answer is no, you can’t access that “tenant query” in your tenanted deployments.

The “tenant query” you build when creating tenanted deployments in the Octopus UI is treated as an transient/adhoc query. It was designed as a way for you to select a list of tenants, and then the Octopus UI calls the API to create one deployment per-tenant. We don’t save that “tenant query” with each of the tenanted deployments.

The tenant tags you can access during a tenanted deployment are (as you mentioned) the tags applied to the tenant for that deployment. This enables some interesting scenarios where you want your custom scripts to alter their behaviour based on how that tenant is tagged.

So I can understand better what you want to achieve: what is the end-goal for the running tenanted deployment being able to access the adhoc “tenant query” used to build a list of tenants in the UI?

Hope that helps!
Mike

3

This parent deployment is triggered from build server with the tenanttag parameter. It will end up only selecting one tenant (dummy tenant because this part of our deployment serves all tenants). As a last step of this deployment I want to trigger the tenant specific project with the same tenanttag so that the actual tenants get selected. I have currently scripted around this by making my tenanttag contain a -#{environment} at the end of the tag and then selecting only that one out of the Octopus.Deployment.Tenant.Tags, but I think this shouldn’t be necessary and the “parameters” that were used to trigger a deployment should be saved and become queryable.

4

Hi!

Thanks for keeping in touch! That’s an interesting idea, but unfortunately it would be an invasive change at the moment.

I think the best course of action would be to raise a suggestion on our UserVoice site with a really good description of this scenario so we can gauge demand.

In the meantime, I think the naming convention approach you’re using will be the best approach for now.

Hope that helps!
Mike