Using variable to reference Octopus packages

Octopus Server
,
1

Server version V2019.10.6

I have a set of environment-specific zip file packages held in the Octopus built-in repository that I need to reference uniquely based upon a lifecycle.

eg prod.mypackage.zip, dev.mypackage.zip

I have a deeply a package step and the package set as:
PackagePackage #{Env.ShortName}.mypackage- from feed Octopus Server (built-in)

However when I go to create a release I get
There was a problem with your request.

  • No package version was specified for the step ‘Package Step’ - Looking at the release it shows as #{Env.ShortName}.mypackage- with no version number, rather than de.mypackage and the version number.

If I were to replace the variable with the name then it works ok, however that breaks our lifecycle deployment.

What do I need to do to get the package name & release version picked up?

3

Hi Marcus,

Thanks for getting in touch! I suspect the reason why you’re seeing #{Env.ShortName}.mypackage when creating a release would come down to the fact that environment scoped variables can’t evaluate at release creation time. Only unscoped variables are resolvable at release creation, meaning you could get around this by adding an unscoped value to this #{Env.ShortName} variable.

If you always deploy first to the Development environment, you could probably set the unscoped value to dev which would fix this behavior and still choose the dev.mypackage ID when deploying to dev.

I hope this helps! Please let me know if I’ve assumed incorrectly anything about your setup, or if you just have any further questions or concerns moving forward. :slight_smile:

Best regards,

Kenny

4

Hi

Is there any way around that?

Unfortunately we don’t run the traditional dev->test->prod environment lifecycle but use environments to cover one of many different production types
we have (for regulatory reasons) So there is a level of randomness in the order.

.

I don’t really want to have to create an entire pipeline for each potential lifecycle or by having a manual chose/dropdown to set an unscoped variable.,
as this will not be the only one that will require this sort of thing moving forwards

Two thoughts as we also have control over what we call the package name (as long as the right type gets to the right lifecycle environment.)

5

Hi Marcus,

Thanks for following up and elaborating on your setup. Since the package ID has to evaluate to a valid package at release creation, you could create a dummy package (that’s never used during any deployment) just to allow the package ID to be evaluated at that time. For example, an ID of something like dummy.mypackage and adding an unscoped value to the variable Env.ShortName to dummy. This way it wouldn’t affect any deployments to environments that have variable values scoped to them.

Would something like that be a viable solution in your scenario?

Best regards,

Kenny

6

I’ll give that a try

Kind Regards

Marcus

7

Actually I think I miss understood what you suggested

The package has to deploy on every release – just the contents of the package are different for every environment so how would setting a dummy help?

Kind Regards

Marcus

8

Hi Marcus,

Thanks for keeping in touch! I’m sorry I wasn’t as clear I should have been! The dummy package is only there to allow the release to initially be created. If no unscoped value exists for a package ID, like in your scenario, that variable has no values that evaluate at release creation, causing you to just see the bound package ID field (#{Env.ShortName}.mypackage).

Any environment scoped values of the variable Env.ShortName will evaluate as expected when deploying to the relevant environment. Meaning the correct package will be selected based on these scoped values, and the unscoped dummy value won’t ever be selected when deploying to an environment that has a value scoped to it. The dummy package and its unscoped value are only suggested as a way to initially create the release.

Does that make more sense? Sorry again about not being more clear initially!

Best regards,

Kenny

9

Hi

Got it, that solved part of the problem however the packages for the environments are not all at the same version – so it’s trying to pull down a
version that may be incorrect for that env. One of the reasons we have different environments

But we would always want the latest for that environment – any way round that?

Kind Regards

Marcus