Issues with the Packages list in the Project Release page

Legacy Uncategorised
1

I’ve found a bug in Octopus 3.3.22 that I’d like looked at - I’m not sure if it’s been fixed in the 3.4 beta 1 version, but I didn’t find any reference that looked like it could have been.

Scenario/Steps to reproduce:

I have 2 environments:
“Prebuild”
“Dev”

I have 2 lifecycles:
“Prebuild” deploys to the Prebuild environment only.
“Release” deploys through my regular deployment lifecycle starting with the “Dev” environment.

I have a project that has 2 release channels:
“Prebuild” assigned to the “Prebuild” lifecycle
"Release" assigned to the “Release” lifecycle (Default).

I have 2 External feeds:
“ProGet-Prebuild” and “ProGet-Release” linked to 2 ProGet feeds similarly named (to stop build versioning from my Prebuild and Release build stepping all over each other).

I have 2 Variables defined in my Library | Variable sets:
“Project1.NuGet.DeploymentFeed” which are set to
"feeds-proget-prebuild" for the scope “Prebuild” and “feeds-proget-release” with the scope undefined.

The feed for the project is set to the #{Project1.NuGet.DeploymentFeed} Octopus variable.

Thus, for Prebuild, the feed is my NuGet Prebuild feed and for general release, the feed is my Release feed.

When my build server calls Octopus it specifies the channel and everything deploys as it should.

When I go to the Project releases page, however, the packages list shows the titles for the deployment steps, with the error:
“The resource ‘Project1 version xxx’ was not found.”

The tooltip shows: Project1 from feed ProGet-Release

This release ran through the Prebuild channel using the Prebuild NuGet feed and thus that version of the package doesn’t exist in the ProGet-Release feed.

Hopefully this is an easy fix.

Thanks,

Ben Alabaster

2

Addendum:

My assumption was that this issue arises because that list is referencing the “default” feed value, ignoring the environment scope - which would be my release feed. Is this page not evaluating the variable properly (i.e. with the correct scope for the release) to obtain the correct feed?

3

Hi Ben,

Thanks for getting in touch! I can understand why you think this is a bug, and why the behaviour was not what you are expecting. Unfortunately I am about to use words to explain why we think this isn’t a bug and why it behaves how it does, sorry in advance.

At release creation time we have no scope. I know you can do a few things like create a channel and create a Lifecycle and only have a single environment for both, but a release itself has no concept of knowing that this will be the case, even if it is so defined. We can never assume a release will only go to a singular environment, as Lifecycles are not scoped when a release is created, even if variables and channels are.

I think (and I haven’t tested this) that maybe the solution will be to scope the feed to your channel instead of your environment, and releases DO have a channel context and CAN assume they will only have one channel. That way you should get the result you are after. It is a slightly different way of thinking which makes it a little bit more maintenance, but should suit. You will also require to have an unscoped or default feed value for cases where a channels value isn’t defined and we need to continue on with the Release creation.

Please let me know if I have explained this badly or you have further questions.
Vanessa

4

Ouch, that’s not what I was expecting (and hoping) to hear.

So I would have to set this same variable in every project for the channel for that project instead of at the global level as Channels are defined on the project, not globally? That’s potentially a lot of extra maintenance effort… perhaps I need to consider alternative deployment strategies for my prebuilds than via channels.

So I have 2 questions:

Is there a way to have a non… er… mandatory lifecycle stage such that I can push to my prebuild environment without requiring that the phase is fulfilled prior to moving to the next phase? Presently it seems to be that you have the option of requiring all or any of the environments of the previous stage to be deployed in order to move on. This would be useful to know even if it’s irrelevant for my current situation…

My prebuild isn’t the build that’s promoted through my release environments and stays only in Prebuild. Am I using the right strategy by using channels to deploy to my prebuild environment only? My prebuild is only a branch build and isn’t yet merged with master, whereas my master branch is what gets built and pushed through my release channel. Is this the intended use case for channels?

Thanks,

Ben

5

Hi Ben,

I do think you have the correct use for channels, and it wouldn’t be such an issue if it was a value needed at deployment time, versus release time.
I do not think it is too much extra maintenance, as you will be linking directly to the feed itself, and once the two variables are setup within your project they don’t really need to be touched.

To specifically answer your questions, there is no way to have a non-mandatory phase in a Lifecycle. You can have non-mandatory environments in a phase by limiting the count of environments that need to be deployed to, but this can mean that one mandatory environment could be skipped which is not ideal. Which answers your second question, yes Channels is the correct solution to this problem.

To ask more questions, How many projects do you have in this position? Are they using the same packages or all individually different projects just under your own process that requires this flow?

It doesn’t feel like a lot of maintenance to set these two values up once scoped to their channels, but that’s pretty easy for me to say.

Vanessa