I am trying to follow your suggestion: You can make this work in Octopus, by creating a package for each environment and pushing them to environment-specific feeds, and then binding the NuGet feed selector in your package steps to an environment-scoped variable.
I have setup a shared file feeds (see attachement 1)
I have setup a Process Step that will look for the Package feed name using a custom variable #{Octopus.Environment.Name} which is the same name as my feed.
The problem is, when I go and try to create a Release, I can’t find any packages.
The problem I am trying to solve is: Be able to push specific environment packages and deploy them filtered by the environment. I.e. Not being able to deploy a TEST package to PROD.
As I said, we have a branching environment, and I know you don’t like it (already spoke with Dalmiro about this).
Thanks for getting in touch! At the time of release creation there is only a small amount of variable evaluation we do. And unfortunately we do not have any environmental context at this stage of the deployment.
As Octopus checks the feed and package at release creation time, even if it is not used later on, we require an unscoped variable with the feed value to be present for us to evaluate.
To fix this, would you be able to do the following:
Create a new variable and call it say nuget-feed with the value #{Octopus.environment.name} and scope it to all desired environments. Then create another variable called nuget-feed and give it the value of the NuGet feed but don’t scope it to anything (you should end up with 2 variables with the same name, one with the system variable as the value and the other with the NuGet feed, but both with a different scope). Then try to run the deployment once again.
This should tell Octopus the information for the feed during the release creation and still let you have the feed scoped to your environments when it reaches the deployment phase.
We notice that this may not be very clear in the documentation so I’m going to add in some information about this to avoid confusion next time.
Let me know how you get on, or if you have any further questions.
Hi Daniel, so far it found the packages, but my next question is:
Do feeds need to be always the same version between the environments?
Remembeber we have a branching setup (which I know you don;t like) but what
I want is, every time I do a release to an environment, it will retrieve
the latest packages versions, which may not be the same one as the initial
release.
In example, when I create the release I have version 0.0.1 deployed to DEV.
But when I run the same process now in TEST, I’m expecting to use the
latest package version there, which may be 1.0.5. Can this scenario still
work here?
I think this problem can be easily solved if, when creating a release, you can choose the target environment and therefore being able to choose the feeds from it.
Unfortunately I think your options are very limited here. Octopus gets it package versions at the time of release creation. The deployment is unable to overwrite this or get the lates version outside of what has been set in the release creation.
No your feeds do not need to be the same version between environments.
I dont think your scenario will work very easily. While you could technically have different feeds for each environment, the version it is set to when the release itself is created will be the version that feed uses.
The other option is to create a new release every time you have a new version ready and then deploy it strait away.
