How set package name in "Deploy to IIS" step template?

[mhorstmann]

Hi folks,

in the “Deploy to IIS” step template…

… it’s possible to dynamically select the package at deployment time:

In this example, the Configuration variable could be Debug or Release, depending on environment.

However, when doing so, it doesn’t appear to be possible to use the --package switch of the create-release command to specify a version number for that package:

octo create-release --project=MyProject --version=1.2.3 --package=*:MyPackage.#{Configuration}:1.2.3

returns

The package argument '*:MyPackage.#{Configuration}:' does not use expected format of : {Step Name}:{Version}
Exit code: -1

This problem actually has a solution when using other step templates. For example, the “Run a script” template, it’s possible to specify the package ID twice: once with the variable for dynamic selection, and then a second time without:

In that case, the package can be referenced by using the second package ID during release creation:

octo create-release --project=MyProject --version=1.2.3 --package=*:MyPackage:1.2.3

How can the same thing be achieved with the “Deploy to IIS” template?

Any help appreciated, thanks!
Max

[Daniel_Fischer]

Hi Max,

Thanks for getting in touch! I have done some testing on my end but the commands you have provided seem to work just fine. I’m wondering if perhaps this issue has been fixed in a more recent version of the Octo CLI or Server.

Would you be able to let me know which version of both Octopus Server and Octo.exe you’re using?

Regarding the #{Configuration} variable on the project with the IIS step, is the value scoped?

Looking forward to hearing from you.

Best regards,
Daniel

[mhorstmann]

Hi Daniel,

Thanks for your response! We’re on Octopus Cloud v2022.2 (Build 1797) and octo version 7.4.3649.

Note that we’re using the .NET Core Global Tool version of the CLI. So the command is actually dotnet octo create-release ....

Yes, the #{Configuration} variable is scoped to the environment. Depending on the environment, it’s either Debug or Release.

To confirm, you’re able to run a command like

octo create-release --project=MyProject --version=1.2.3 --package=*:MyPackage.#{Configuration}:1.2.3

with the #{Configuration} parameter and it succeeds?

Thanks!
Max

[Daniel_Fischer]

HI Max,

Sorry for the delay in getting back to you here. On a closer inspection, the commands are most definitely not working as expected on my end. However, I don’t see the errors that you do. There is potentially multiple bugs at play with this --package option.

First off, it looks like the wildcard option is not working when used for the step name. Octopus just ignores the option and deploys the latest release. Setting a wildcard for both step and package, or just defining a package and version seems to work fine.

The other issue appears to be with using an Octopus variable in the command. I’m of the mind that this should work but it doesn’t appear to. I have raised both of these to our developers and they are currently looking into them.

Unfortunately I don’t have any workarounds or GitHub issues to link as of yet. However, I’ll keep you updated with our developers findings.

Let me know if you have any questions or further thoughts here.

Best regards,
Daniel

[mhorstmann]

Hi Daniel,

Thanks for your response, appreciate your help.

We can work around it for now by using the --defaultPackageVersion switch.

For a long-term fix, I recommend suggesting to your engineering team to add the second package id (package name) field to the “Deploy to IIS” template, similar to the “Run a script” template.

In the following output of octo create-release, steps 3 and 4 use the “Deploy to IIS” template and you’ll notice that there’s also no “Package Name”:

This appears to further indicate that there’s a missing package name filed on that step template.

Thanks again!

Max

[Lauren.Cagney]

Hi Max,

Thanks for the step template suggestion! This recommendation has been passed on to the developers looking into this issue.

For now it sounds like the --defaultPackageVersion switch will be your best option. Once the Github issue has been created we will post a link here so you can subscribe to it and stay up to date with any changes.

Please reach out if you have any further questions!

Kind regards,
Lauren