Redeploy a release with the variable snapshot of last release

[praveendvd0pravu (Praveendvd)]

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

[Bob_Walker]

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?

[praveendvd0pravu (Praveendvd)]

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 ,

2. 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

[Bob_Walker]

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.

[praveendvd0pravu (Praveendvd)]

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 doesn’t feels as if its just about adding steps as child step

[Bob_Walker]

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

[praveendvd0pravu (Praveendvd)]

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

[Bob_Walker]

You are welcome!

[praveendvd0pravu (Praveendvd)]

Hi @Bob_Walker ,

How you doing , I implemented this and it works as expected but we have came across one UI issue ;

This is the rolling project configured

The step get skipped as expected , but in UI only the fiest step shows as skipped but the remaining shows as executed (Even though it won’t execute)

Should i raise a bug for this ?

[Bob_Walker]

Where did you put the variable run condition? Any step in the rolling deployment can have a variable run condition.

Parent step:

Child step:

[praveendvd0pravu (Praveendvd)]

the condition is in the parent level . So the expectation is that the steps inside “Test” shouldn’t run and it is working as expected but the problem is UI shows green tick even if the steps are not actually executed

[praveendvd0pravu (Praveendvd)]

just create a new multi-step project , with the parent level has run on condition false

now add two powershell script steps with content as :

  Write-Error something

Now you can see that when you create a release , the script won’t get executed but the step shows green tick instead of skip -

[Bob_Walker]

Okay, it sounds like you running into this bug: When a Parent Step has a run condition evaluate to false, the child step will highlight green as if it ran, even though it didnt. · Issue #6635 · OctopusDeploy/Issues · GitHub.

[praveendvd0pravu (Praveendvd)]

Exactly thank you, good to know it’s been already tracked. Thanks Bob

[Bob_Walker]

You are welcome!