Multiple steps referencing same package

Suppose that for some reason we need multiple steps referencing same package (for example one step will do something with docker image and another will deploy it to kubernetes)

While we are adding references to steps we retrieve following picture on release creation:

Screenshot 2020-06-10 at 08.41.30

Which introduces possible misconfiguration

Wondering if this is by design? (in my understanding package references might/should be deduplicated or at least it should be configurable)

At moment possible workaround is to create empty script step which will reference package and then in all other script steps use its reference like so:

VERSION=$(get_octopusvariable "Octopus.Action[reference].Package[dictionaries].PackageVersion")

And probably inside kubernetes deploy containers steps it will be something like:

gcr.io/#{Octopus.Action[reference].Package[dictionaries].PackageId}:#{Octopus.Action[reference].Package[dictionaries].PackageVersion}

But it becomes unmanageable

Wondering if there is any other workaround for this topic

Hi @svc,

Thanks for getting in touch!

This is by design as there are many scenarios that Octopus has to account for so it needs to be able to allow selection of different versions if needed.

There are a couple other options that come to mind.
The first would be to move the creation of releases to your CI server, this would automate the process and remove the chance of incorrect package versions being selected. I do realise that this could be a big change though.

The other option would be to use a separate project to orchestrate your releases and deployments with a Chain Deployment step. This isn’t the most elegant option though.

I hope this helps provide some direction for this, please let me know if you have any additional questions.

Regards,
Paul

Hello,

Yes, I do agree that there are cases when we gonna need different package version, but opposite is also true - that is the root cause of workarounds, without ability to control this we always be working on hacky things :slight_smile:

Thank you for suggestion about creation of releases in CI - indeed it gonna work, unless someone will create release by hand. But also it will blow up overview dashboards for projects with frequent commits

As about chaining - I even not sure whether it will make things even more complex and hard to investiage

At moment, I’m thinking that leaving everything as is, creating releases in CI, and writing docs to engineers will be the best option here

Hope to see some support for such scenarious in future (e.g. at the project level settings switch to tell whether duplicated packages should be combined or not - it seems like a frontend task only, because underneeth still each step will receive his pacakge the difference is only in ui)

I’d like to dig into how we could possible make a change to improve this in future.

I previously had a similar setup where my project had slightly different process steps depending on the environment being deployed to, but all of the steps used the same package. The number of people creating releases was extremely small so it never really became a problem but having some form of grouping by default would have helped.

My current thought would be an option within Project > Settings to specify whether packages of the same name should be grouped by default or not in the release creation screen.

And then a second option within the release creation screen to override this and group/ungroup the packages if needed.

Does that align with how you could see this working?

Yep, totally and what is really cool about this - it is just ui change, e.g. even if I turn on package grouping, underneath there still be setup of package for each concrete step, so it is doable only on frontend, and reversible if needed

1 Like

Here is how it might look like

Lets imagine that there is an “Use same version for packages” checkbox on release creation page, which is turned off by default (so wont brake current behaviour)

And if I as a user turn it on, then changing version of any steps package will propagate to all other steps (e.g. I did changed version of step2, step1 version did also changed accordingly)

That was what I meant when talking that this is more frontend stuff and doesnt require huge invesments

1 Like

BTW Here is one more against automatically creating releases for each build - we will hold artifacts for them which will blow up storage consumption