Dynamic package id

Legacy Modelling
1

Hi,

I am using Octopus to deploy to an Azure cloud service and have two steps in my deployment. The first step generates the .cspkg (cloud service package) file for an environment (there are ~12 environments) using a Powershell script (as Octopus doesn’t support creating .cspkg packages natively) and the second steps deploys the .cspkg.

As mentioned, because I have several environments with each having specific azure cloud configuration, each package that is generated in step 1 is different from other environment packages. Therefore in step 1, I want to create a package with a package Id of something like package_name_#{environment name} - where #{environment name} is an Octopus variable.

I have tried to achieve this but Octopus is obviously parsing the configuration of both package Ids in both steps (before running the deployment) and telling me that the package Id I have entered in step 2 is incorrect (step 1 is fine as I’m using the package Id of the package that was initially uploaded to Octopus from TeamCity therefore it exists hence no issue) - because it doesn’t exist yet as step 1 hasn’t run.

The exact error is: The step failed: Activity failed with error ‘The package “my_package_name.my_variable_name” could not be located in the built-in repository.’.

Is what I’m trying to achieve in Octopus possible?

Cheers,
Darcy

2

Hi Darcy,

Thanks for getting in touch! I may need to grab some more information to better understand your scenario, but I can also give you my thoughts on your scenario based on the information you provided. :slight_smile:

You mention that you are using package_name_#{environment name}. Are you able to confirm that you are actually using the system variable #{Octopus.Environment.Name} to set the package name and that this variable is evaluating correctly. I’m not too certain if you already have this configured correctly and just used #{environment name} for the example, or perhaps as a scoped project variable. I have pasted the documentation for our system variables below. :slight_smile:

Would you also be able to attach a full deployment log where you are getting this error? This will give me a much better idea of what could be going on.
Four our documentation page on retrieving the deployment log, see the following link: https://octopus.com/docs/how-to/get-the-raw-output-from-a-task

So the error aside, from what I can see, it looks like this could be handled a bit easier by transforming the .cspkg that is inside your NuGet package using scoped variables. This can be done as a part of the deployment step by substituting variables in a file.

Octopus lets you place variables inside your .cspkg which is pre-packaged, including its name, Octopus could then evaluate those variables at deployment time. They can even be environment specific based on variable scoping. (See link below)

Example:
Inside my NuGet package, I have MyPackage.#{Octopus.Environment.Name}.cspkg Then inside that, any data that needs to be variable based on environment could be a project variable.

You can create variables to represent any data that may change in the file, for example I create the following project variables:

Variable name = connection.string | Variable value = http://server.123 | Variable scope = Dev
Variable name = connection.string | Variable value = http://server.456 | Variable scope = Test
Variable name = connection.string | Variable value = http://server.789 | Variable scope = Prod

If you were to then place the #{connection.string} variable inside your .cspkg, Octopus would evaluate the value based on what ever environment it is scoped to. So deploying to Test would evaluate the file name as MyPackage.Test.cspkg and it will contain the evaluated variable of #{connection.string} as http://server.456.

See our documentation for some more detailed information here.

I may have made some assumptions on what exactly you are doing here. If I am wrong, some more information on how your deployment is configured to run and the deployment logs will give me a much better idea.

Let me know what you think. :slight_smile:

Best regards,
Daniel