We have configured an application deployment so that for speed it runs two rolling deployments to update both the front and backend of our software in parallel.
The rolling steps come about halfway through the deployment process and at a high level do the following:
Uninstall software
Attach logs as Octopus artifact
Install software
Attach logs as Octopus artifact
The issue I am having is the Rolling Child Steps only have two run conditions: Previous Child success and Variable Condition. If the uninstall/install fails - that’s arguably the time we need the logs the most. Having it quit the rolling deployment because the uninstall failed and not grabbing the logs is becoming an issue for us.
Now obviously if these steps were these “normal steps” they would also have the option for “Always” or if previous step fails and we could set it up to Always run. However that’s going to require a fair bit of work to rejig the process and ensure that all the steps can still run in parallel etc.
Short term if we can come up with a clever variable condition which always evaluates to true if the previous step has run (success or failure) that should work.
So effectively something like:
If Uninstall Step executed > Always run
I’ve tried the following condition, with the step name substituted for the appropriate child step
#{if Octopus.Action[StepName].Output.HasRun}{/if}
However I can’t seem to get this to evaluate as True. It currently is skipping the step in both success and failure states.
Apologies for the obvious question first, but is the HasRun output variable being set during the Uninstall step, e.g. Set-OctopusVariable -name "HasRun" -value "True". This would mean that if the Uninstall Step fails before it reaches the end of the script to set that output variable, then the log step should run, but if the script completes, it will be skipped.
e.g.
Success of the Uninstall step:
Failure of the Uninstall step(and ignore via Guided Failure):
Thank you for asking the obvious question, I hoped I was missing something obvious!
I’d misunderstood the examples I’d seen. I thought it the variable was a built in auto-populating one, I missed that subtlety where you actually have to set the value.
Now I’m explicitly setting the variable our log flow is behaving as expected and I can set subsequent steps to not run if the Install fails. So that’s perfect.
It would be nice if all 4 native run conditions for steps were available on rolling steps, but now I know what I’m doing it’s not a big deal.
A quick follow up on this, I spoke with our engineers and having the additional run conditions available in these child steps is something that was originally intended, however, during implementation the complexity of achieving this was too much for the work cycle.
It is something we still wish to add, but as it will require some bigger architectural changes to accomplish it may be a while until we have the resources for it.
