Is there a way to get a specific Octopus.Release using Octopus.Project.Name/Id for the current environment using system variables? I know I can do this via the Octopus REST API, but it would make step templates far simpler if this could be passed as a parameter.
Hi Clayton,
Apologies for the late reply.
No, the variables don’t contain values for past releases. Would you be willing to share a little more about your scenario? Perhaps there’s something we can do better, or another way to approach it?
Hey
Thanks for getting back, I didn’t know if I had used the right channel to ask about this. What I would like to do is get the current Release in the current Environment using a Project.Name or Project.Id via Octopus system variables. This would allow me to do several things specific to a particular release from other contexts.
For example, if you could pass Project.Id to a Release then you might be able to do something like “#{Octopus.Release[#{Octopus.Project.Id}].CurrentForEnvironment.Id}”. Doesn’t need to be that syntax specifically, but hopefully that helps illustrate what I’d like to do.
There are the following variables:
Octopus.Release.PreviousForEnvironment.IdOctopus.Release.PreviousForEnvironment.NumberOctopus.Release.CurrentForEnvironment.IdOctopus.Release.CurrentForEnvironment.Number
which will always be populated for the currently executing project. See our docs for more details.
There is no need to pass the project ID if it is the project being deployed that you are interested in.
If it is not the current project you are looking for, then unfortunately there are no built-in variables which will help. You will need to call the Octopus HTTP API for those.
Is it the project being deployed you are looking for the previous release details of?
No, I am trying to access it from another project. I had a feeling that I need to write a script to accomplish this instead.
I am using the “master project” philosophy to coordinate releases for a series of microservices, so something like this would be useful for multiple step templates. Is there any chance something might get added to the system variables for this?
Have you seen the Deploy a Release step? It was designed to help with this scenario.
Would this fit for you?
That’s exactly what I am doing actually. I have several steps after deployment that will rely specifically on the package version currently deployed to the current environment, but in some cases the package will not be deployed by the current release. That’s why I need to get a release by using the current environment and a project.
Perhaps it would help to describe the scenario better. I’m setting up a deployment process for a server team that utilizes Octopus for a microservices architecture. We have (up to) 14 packages that can part of a weekly release and I’m using the Deploy a Release Step Template to have a master project that deploys each thing in the right order, some in parallel, some not, etc.
What I would like to do is also run our API and UI tests in this pipeline at appropriate times so that I can make certain deployments wait until testing passes against a previous one (a service with an API that is used by another service). In order to run the right version of tests, I need to know which package is referenced in the child release. The problem is that because of the abstraction, I haven’t been able to get what I need from the child release without adding something more custom.
It would cut out a lot of boilerplate if I could use a System Variable as a parameter for a Step Template. There are already ways to get a Package from other contexts so I was hoping there is an existing combination of variables to get what I need. If not, it appears that I can either have all of my child Releases provide the Package metadata as output variables or write a few calls to the Octopus REST API in my step template.
Do you have any suggestions? Thanks for your time, btw. I really appreciate it.
Hey Clayton,
Thanks! That description did give me a better understanding.
When you create a release of the parent project, the version of the child project you select is actually captured as a package variable.
This means you can use this:
Octopus.Action[Deploy Release Step Name].Output.Package.PackageVersion
This will give you the selected release version of the child project.
And even further, any output variables created as part of the child project are captured as output variables on the Deploy Release step. For example, you can use:
Octopus.Action[Deploy Release Step Name].Output.Deployment[Child Step Name].Package.PackageVersion
to get the version of a particular package deployed by a step in a child project.
Aaaand, you can then pass these values down into other child deployments (e.g. your API test projects), using the variables field of the Deploy Release step.
I hope that makes sense. Would this help in wiring the pieces together?
That is exactly what I was hoping for, thanks for the thorough explanation. This simplifies things considerably.
It appears that this does not work out of the box; do I have to add PackageVersion and PackageId as Output Variables manually to steps in the Child Releases? Seems like there would be a way to get it since it’s s System Variables in another context.
@Michael_Richardson After adding output variables manually to the projects I want to reference from the Deploy a Release step, it appears that it relies on the target action running and not getting skipped. If this is correct, then this ends up not being a possible workflow because not every package will go out every release, but we do want to run specific sets of tests regardless. For now it seems like I’ll need to write a script to get the release from Octopus’ REST API.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.