Using dynamic Package ID

Hello,

I am having trouble using dynamic package ID in one of my steps. I need to be able to dynamically specify the name of the package and have it pick the latest version or specify the version.

I have a step that needs to run a PowerShell script that is contained in a package. This package id needs to be dynamic.

I have a project variable called IaCPackageId which is set to the name of the package. It is defaulted to DataPump.Infra in the project variables. This is because it appears that OD needs to be able to resolve the package name during release creation. I need this value to be changed during deployment. This is driven off of a #{Project} project variable which is a dropdown.

image

I have a PowerShell step that will determine the package name based on the current project its deploying. Eg. Monitoring.Infra

Once I determine the updated value in my PowerShell step, how to do I update the project variable?
Typically I would set the project variable #{IaCPackageId} = #{Octopus.Action[Determine Application Package Name].Output.IaCPackageId}
But I cannot do this as this won’t resolve during release creation time.

A similar question has been asked, and solution 1 seems to imply there is a default value for dropdown but I can’t seem to find it the option in OD while creating a drop down variable.

Some help would be much appreciated, thanks!

Update: Looks like setting #{IaCPackageId} = #{Octopus.Action[Determine Application Package Name].Output.IaCPackageId} on the project variable is working. It trying to pull the appropriate package based on the project selected in the dropdown but its erroring out when trying to get the right version. It seems to be getting an incorrect version (the version that was specified when the release was created) instead of the latest. Any way to fix this? Also I don’t see how/why it picked version 2021.2.10.44331.

Hi @kingk,

Thanks for getting in touch!

When using dynamic package names, it is assumed that the packages being selected between will be on the same version.
e.g.
A deployment that targets different tenants and each tenant has a slightly different config file in the package. All the packages would be built at the same time, so, have the same version number but slightly different names.
TenantAWebApp.0.1
TenantBWebApp.0.1
TenantCWebApp.0.1

Looking through your post it looks like you’re aiming to compress several different projects within a single project and have the user select which one they want to deploy using the drop-down. If this is the case we would strongly suggest splitting these into their own separate Projects within Octopus.

This would completely remove the need for dynamic packages(which we recommend to avoid if possible), remove the need for the user to interact with a drop-down and allow you to easily see what versions are deployed using the Octopus Dashboard.

If this project has a number of standard steps that will apply to all of these projects and you want to avoid duplicating them and increasing the workload when changes are made. Then you could perhaps use the Deploy a Release step to set this as a Parent Project and then have a smaller Child project for each of the microservice packages. You could then control which Child projects are deployed by either using a drop down variable within the Deploy a Release step or having a separate Deploy a Release step for each Child project and using the Step Include\Exclude options at deployment time.

There is more information on this kind of configuration available here: Coordinating multiple projects - Octopus Deploy

Regards,
Paul

Thanks Paul. The assumption that all packages will have the same version number is rather limiting. This isn’t necessarily the case as they might be built at different times and this dependency hugely limits the usability of this feature. Is there a plan to allow including version numbers too?

Also how do you change the package names? As I mentioned above using a variable that is set at deploy time doesn’t seem to work because it needs a value assigned at release time. And if that value is coming from a user dropdown it is not available until deploy time. Is there a way to specify a default value for a dropdown?
I end up with an error message like below because I didn’t specify a version when I created the release.
The step failed: The package '#{Project}.Infra' is required by 'Deploy IaC', but no version has been specified.

There are no plans currently to expand the dynamic package functionality to include scaling version numbers. A lot of Octopus features are dependant on the package name and version being available before the deployment starts, so, whilst it is possible to use dynamic packages we do encourage other options to be used where possible.

When using a drop-down variable the configuration is a little misleading. The default value goes into the Value box on the right and the drop-down options go into the tiny box on the left.
e.g.

Thanks for the quick response. Wow, that is totally misleading. I hope you have plans to fix that.

I guess then my follow up question is how can I download the package from the feed, unzip it and have the files available to be used in the next step.

If all of the possible packages are likely have different version numbers then I don’t see a way to achieve this using dynamic packages here.

The best option I can see would be the one I outlined above and split the package deployment for each of these into separate projects. Each of those projects would have their own releases with the correct package versions assigned.

Then in this original project you could have a Deploy a Release step and then use the drop-down variable in the Project name field within this step.

I think I am going to create a script that will do this for me as a step. I have most of it ready.

Is there a way, possibly using a system variable, to access the configured external feed URL using the feed id?

To access the external feed information you would need to make a call against the REST API (<octopusURL>/api/<spaceID>/feeds/<feedID>)

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