Skip step if previous step ran on a system

Octopus Server
, , , ,
1

So I have multiple systems to deploy to and in my project steps we do the following, and much more but the gist of what I’m trying to accomplish is this:

step 1 “Deploy Website X” (WEBSITE_TARGET_ROLE)
step 2 “Deploy Package X” (DEPLOY_TARGET_ROLE)
etc…

System 1 (WEBSITE_TARGET_ROLE, DEPLOY_TARGET_ROLE)
System 2-n (DEPLOY_TARGET_ROLE)

The Deploy Website is only done on 1 server and all other servers get the Package. I’m trying to find a condition to skip the “Deploy Package X” step if the “Deploy Website X” has been run on a system.

I tried using the following “Run Condition” for the “Deploy Package X” step:

#{if Octopus.Action[Deploy Website X].IsSkipped == “True”} true #{/if}

Which I thought would be per machine where if Step 1 wasn’t run on this system, then run the “Deploy Package X” step…but since the “Deploy Website X” was run on one system, this condition evaluates to False so the “Deploy Package X” is skipped on all systems.

Am I missing something, my boss states he doesn’t want to create any more roles, which to me would be simplest but is there an easy way to do this?

Thanks

5

Hi Tom,

Welcome to the Octopus Forums!

You are right, more roles would be the easiest way but if that’s not an option we can probably do this with a workaround. For the workaround to work you need to be on 2020.2.4 or later, though. There was an issue with machine level variables in run conditions that was fixed as shown here: Github Issue 3206

Essentially what you will need to do is create a step after “Deploy Website X (WEBSITE_TARGET_ROLE)”, that is a script step that only runs on that role, and set an output variable to true, like this.

Set-OctopusVariable -name "HasRun" -value "true"

This will create a machine-specific output variable that we can later reference in a run condition so that the other deploy step won’t run against those targets.

In the later deploy step, go to the bottom of the step and go to “Run Condition”, and change it to “Variable. Only run when the variable expression is true”. The run condition you will want is

#{if Octopus.Action[STEPNAMETHEOUTPUTVARIABLEWASCREATEDIN].Output[#{Octopus.Machine.Name}].HasRun == "true"}false#{else}true#{/if}

This makes it so the step will only run if “HasRun” doesnt exist for the machine (meaning a machine was never targeted with that earlier script step), or if for some reason that variable is set to false.

Let me know if this works for you or if you need further assistance.

Thanks,
Jeremy

6

Thanks, Jeremy, I did find that solution and now I see why it most likely wasn’t working for me, we’re on version 3.12.4. The individual who set up our Octopus server had recently left and I’m taking over maintaining this system, I didn’t realize how far back we are in versions…but I know they don’t like change here because of possible client impact so I may have an easier time adding a role than upgrading the server. I’ll talk to the powers that be and push for the server upgrade…we’ll see.

Thanks again.
Tom

7

So, he doesn’t want me to do either, wants me to come up with another way. So if I add a PreDeploy script, I’m assuming I can use a PowerShell script to check if the path of the deployed package exists:

[System.IO.DirectoryInfo]$filePath = $OctopusParameters[Octopus.Action[Deploy Website X].Output.Package.InstallationDirectoryPath]

if (Test-Path $filePath)
{
can I skip this step here somehow?
}

8

Hey Tom,

I have a couple ideas but since you’re on such an old version I’m not sure the features will work. I will have to setup a custom VM to do some testing. If you want to do testing on your own in the meantime you could attempt to do the check in your pre-deploy script step and use the green highlighted part at the bottom about “Skipping conventions”. https://octopus.com/docs/deployment-examples/package-deployments/package-deployment-feature-ordering

Let me know if you have any questions.

Thanks,
Jeremy

9

Thanks Jeremy, I did find that earlier but doesn’t seem to work for me. It seems the custom Pre-Deploy script runs after the package is deployed and extracted! If you check out the image, you see how it adds the “_1” because the package is already there - that’s what I’m trying to avoid.

PreDeployment
PreDeployment.JPG701×236 22.4 KB

OctopusDeploy
OctopusDeploy.png771×170 7.25 KB

T

10

Hey Tom,

In the same script you could delete the extracted folder, cleaning up the extracted package before running the short-circuit command. I’m not sure you can block the package from transmitting and extracting if you’re using a pre-deployment script. We potentially could try some really hacky stuff but if this works it will be much simpler and more elegant.

Let me know what you think.

Thanks,
Jeremy

11

I keep getting a Files in use message trying to delete the folder. I’ve tried it in Pre-Deploy and Post-Deploy using the following:

$websitePath = $OctopusParameters["Octopus.Action[Deploy Website - X].Output.Package.InstallationDirectoryPath"]
$packagePath = $OctopusParameters["Octopus.Action[Deploy Package - X].Output.Package.InstallationDirectoryPath"]

if (Test-Path $WebsitePath)
{
    Remove-Item -Recurse -Force $packagePath
}
12

Hi Tom,

Octopus must be locking the files during the step, which makes sense. Sorry, I didn’t think about that.

Unfortunately, I think we may be getting into hacky workaround territory. I do have an idea, but I haven’t tested to see if it will behave the way I’m hoping. Before we do that, will this always only be one machine, or is there a scenario where “Website X” will get deployed to multiple targets?

Thanks,
Jeremy

13

Correct, the Website will always be deployed to the one machine, all others get the same package.

14

Hi Tom,

What you could try instead is, short circuit it if website path exists so that it doesn’t deploy package x, then in a following step run a script step on the website role to delete the path of package x. If it has relinquished its usage this should work to clean up the folder I think.

Can you give that a try and let me know if it works?

Thanks,
Jeremy

15

So, when you say “short circuit it if website path exists so that it doesn’t deploy package x” - this is exactly what I’ve been trying to do.

I’ve been trying different forms of the run condition of the Deploy Package step in the form of a Test-Path - but I can’t seem to get it to work.

#{unless Test-Path Octopus.Action[Deploy Website - X].Output.Package.InstallationDirectoryPath}True#{/unless}

If all else fails with the condition, I can most likely add a cleanup script after the Deploy Package step that will get install dir of website and package and if they are different, delete the package.

Thanks Jeremy,
T

16

Hi Tom,

Does the short circuit command in the pre-deploy script work to stop the rest of the step? Or does the short circuit command not work at all in your version?

**Skipping conventions**
Any of the scripts run during deployment may set a variable to short-circuit the process and skip remaining items, as with this example in *PowerShell* :

`Set-OctopusVariable -name 'Octopus.Action.SkipRemainingConventions' -value 'True'`

If it doesn’t work at all I apologize. If that does skip the rest of the step, you could have the deploy package x step run it in the pre-deploy script triggering on “does website x package exist”. Then after the deploy package x step, run a cleanup script on the website role that deletes the files from package x that got unpacked.

Let me know if that works for you.

Thanks,

17

So I ended up just adding a script to remove the duplicate folders:

$websitePath = $OctopusParameters["Octopus.Action[Deploy Website - X].Output.Package.InstallationDirectoryPath"]
$packagePath = $OctopusParameters["Octopus.Action[Deploy Package - X].Output.Package.InstallationDirectoryPath"]

if ((Test-Path $websitePath) -and (Test-Path $packagePath)) {    
    if ("$packagePath" -ne "$WebsitePath") {
        Remove-Item -Recurse -Force $packagePath
    }
}

Thanks for your help Jeremy.

18

So I was responding when you were. I didn’t even bother with adding any pre or post deployment to any other step, just literally added that script after the Deployment Package step, having the same role as it. Got a few more tests to run but looks like that will do the trick.

19

Hey Tom,

You’re very welcome. I’m glad to hear it looks like we have a workaround going for your setup. Please reach out if your further tests end up not working and we can try to think of an alternative.

Thanks,
Jeremy

20

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.