Redeploy a release with the variable snapshot of last release

version: v2020.5.8

Hi Team,

I have a deployment step of deploy a release in one of the parent project , we have few variables that gets injected to the child project , and needs to redeploys the child project using scheduled triggers weekly.

But the redeploy-release doesn’t has the variable snap shot of the values passed from the parent , so its not what we want.

Is there a way to trigger last deployment with the variables from parent project

Couple of clarification questions:

  1. The child project has prompted variables which are provided by the parent project? Who provides the parent project with those values? Are they hardcoded in the step or are they also prompted variables?
  2. Where does the trigger exist? On the parent project or the child project? If on the child project, have you thought about moving the trigger to the parent project?
1 Like

Thank you for replay
1.

We are pushing the parent project details to the child project which runs some test scripts. We want to weekly run the test against the parent ,

  1. So we have the trigger on the child test trigger project , we don’t want to redeploy the parent project weekly as its already deployed and is up and running. We just want to trigger the child test trigger project but should have the variable value for ApIServerURl, OctopusReleaseNo etc as the snapshot

Unfortunately the variables that are being sent down to the child project are part of the deployment variable manifest. They are not part of the release snapshot. Each time a deployment is run the variables from the release snapshot are copied over to the deployment, during the deployment other variables are injected (such as prompted variables, task id, deployment environment) or created during the deployment run itself (such as output variables).

There are a couple of options to pull those values.

The first option is to save those values to a json file on a shared drive when you call the child project from the parent project. When the child project runs it can see if values are passed to those prompted variables, if they are empty, then you could read from that json file and use those values.

The second option is to have a run a script step at the start of the child project. That script will use the Octopus Deploy Rest API to find the last deployment of the child project, then pull the deployment variable manifest from the rest API.

This will get you all the deployments that were successful for a specific project to an environment.
/api/tasks?skip=0&take=100&spaces=$spaceId&includeSystem=false&project=$($project.Id)&name=Deploy&states=Success&environment=$sourceEnvironmentId

That will return this:

Using that deployment id you can then query this endpoint

/api/[space-id]/deployments/[deployment-id]

That will return this object:

Using that endpoint you can then pull back the variables used in that deployment. That will return an object like this which you can loop through to find those values

From there you can set output variables (Output variables - Octopus Deploy) to be used by later scripts.

1 Like

Thank you Bob but this seems to be a lot of rework than a straight forward solution .

What is your call on using A rolling deployment process : Steps - Octopus Deploy

we were planning to keep the Deployment inside one step called “Deploy project” and test trigger in another , and trigger deployment only if its not from Octopus.Deployment.Trigger.Name!=="weekely trigger" else trigger only tests.

Does this approach has any issues, because i feel "Rolling deployment process sounds scary :smiley: doesn’t feels as if its just about adding steps as child step

Without knowing all the details, at first blush the run condition skipping when a trigger is invoked seems to be the most reasonable.

1 Like

@Bob_Walker Thank you so much i will have a go with it then

You are welcome!

1 Like