Run Pre-Deployment Script when creating a new release

Legacy Uncategorised
1

Scenario:

  1. Define a Project variable “DeploymentPackageName” with a value of “XYZDynamicPackageName” (or any value, the point is to have the variable.
  2. Create a Step Template of type ‘Deploy a package’. and for the Package ID value enter “#{DeploymentPackageName}”
  3. Enable the “Custom deployment scripts” feature
  4. In the Pre-Deployment (PowerShell) script enter:

Set-OctopusVariable -Name ‘DeploymentPackageName’ -Value ‘ActualPackageName’

  1. Save the template and use it to add a new step to your project
  2. Create a new Release…

The list of packages shows the value of the Variable assigned in the configuration, not the one assigned in the Pre-Deployment step. It would be nice to have maybe another type of script, say, Pre-ReleaseCreation, that executes when I create a new release. That way I could use a convention-based naming system for the “Step name” fileld and parse the “Octopus.Step.Name” system variable in the PowerShell script to determine the name of the package to deploy. This is very convenient when you have a lot of steps to add to a project and you are frequently defining new projects with vary similar sets of steps (since we do not have project templates).

It looks like I can get away with just entering “Octopus.Step.Name” in the Package ID" field and that works but then I have no flexibility for the convention I want to use to name the steps. And I would really like to have something more than just the package name in the Step Name, maybe a verb like “Deploy”. So my Step Name could be Deploy Package - ActualPackageName and the name would be more meaningful.

Anyway, food for thought.

Thank you for reading.

-OmarV

2

Note… If I had the ability, I would also use the convention-based step name to determine and set the Custom Install Directory field

3

Hi OmarV,

When defining your project variables, you can scope them to steps. So could you not define the DeploymentPackageName variable for each step in your project variables? And the values of these variables can of course contain other variables.

e.g. Your project variables page would appear as:

Name, Value, Scope

DeploymentPackageName, MyPackageA, Step1
DeploymentPackageName, MyPackageB, Step2

Would this work for you?

Regards,
Michael

4

Thank you. The point is that I want to use the variable in the Package ID field and the value to be assigned via the Pre-Deployment script. With this approach, when I click ‘Create Release’ the value of the variable is not the one that I want it to be so it presents an incorrect package name, it cannot find it in the corresponding feed so there is only the option of selecting a “Custom” version of an inexistent package to be deployed.

image001.jpg

5

The short answer is you can’t set the package ID in the pre-deployment script. Octopus needs it before then to download the package.

Out of curiosity, why do you want the variable to be assigned by the pre-deployment script, rather than as a project variable? Using project variables would give you as much flexibility as you like regarding the format.

6

To have a convention-based approach, where the name of the package can be inferred from the Step Name. I have a deployment with large number of components and filling out all the fields for the “Deploy a package” type was a chore. I ended up creating a Step Template with all the fields pre-populated and the Package ID field set to #{Octopus.Step.Name}; so now I just have to put the name of the package in the “Step name” field. It is very convenient when you have a lot of steps to add. I would have preferred the step name to have a different naming convention, that is why I would have liked that functionality, but I still like the way it turned out without it.

image001.jpg