Hi,
We use custom binding of the NuGet feed property on the NuGet packages. This is a great feature since it allows us to promote builds to different NuGet feeds as they pass through our deployment pipeline. We want out production environments to use a different NuGet feed than the one we use for our test environments. This feature allows us to do this using Octo.exe.
But: When this property is bound it is no longer possible to create a release using the user interface. If you click the create release button you will see that the Latest column is empty. If you try to search for a specific version you will get an error page. I guess this is because the the property has not been bound to an actual value in these cases so there is no nuget feed to search in. If you added some UI to bind the property when creating a release using the UI then this would work again.
Any thoughts on this?
/Jan
There are similar issues when the package names are custom-bound. Places in the UI that use to display the package name are currently failing.
Hi,
Yes, since you have multiple potential feeds for the package step, the difficulty is in knowing which one to query when listing package versions - how could Octopus know which one to use?
If we extended the binding syntax to support something like #{YourVariable|feeds-123}, where the second part becomes the default value if the first part can’t be resolved, would that work? Can you set one feed to be the one that we always query when creating releases via the UI?
Paul
Hi Paul,
I think your suggested solution would work.
/Jan
Paul,
a default value will work. That would make variable binding on package
names work as well.
A thought here, is the default value something that would be nice to define
on the actual variable declaration? So instead of having to specify
#{YourVariable|feeds-123} wherever the variable is used, you define
"feeds-123" as default value for YourVariable as part of the variable
declaration(s). So wherever that variable is used, in binding or otherwise,
the default value is implicit.
Possibly, I do not see all implications here. I guess the initial problem
is that you’re not evaluating bindings when displaying them in the UI. A
default value declared on the variable would require that you evaluate
bindings I guess.
Peter Lillevold
System Developer
peter@kodecompagniet.com
Mob.: (+47)480 06 415 | Lync: peter@kode.cc | skype: plillevold
KodeCompagniet AS
http://www.kodecompagniet.com
Any of these solutions would work for us. When working in the Octopus UI, creating a new release or looking at a release we want to use the default feed. This is the feed located at the same location as the Octopus server. When deploying to an environment located in another part of the world we would like the tentacles to download from an alternative feed located close to that environment.
Since our deployment process contains close to 40 packages it would of be much easier to specify the default value in the variable declaration and not in each reference to that variable
/Jan
Hi,
Let me look into whether we can evaluate variables before rendering this page. We won’t be able to know the current environment, so variables scoped to a given environment won’t be found, but if you have an unscoped variable it should work.
Paul
What is the status of this? Our setup is similar to Jan’s, we want to promote changes to different feeds and use the different feeds for different environments. But we’d also like to be able to define a default to be used from the UI.
Hey what do you know… there is a working solution to this posted by Paul at
https://github.com/OctopusDeploy/Issues/issues/671 in the comments. I just hadn’t scrolled down far enough earlier.
Thanks
Hi Beth,
It’s awesome that you found this, I was going to create a screenshot of how to setup the variable, but there it is.
Vanessa
Hi,
Yes, this work’s fine now. It really was a showstopper for us not being able to have different feeds for different environments.
There is however one bug that you need to be careful to avoid.
When you enter the #{Feed} variable and save everything works fine. But when you open the package in Edit again the #{Feed} variable is evaluated in the designer to the first of the feeds e.g. feeds-1. If you change something else and save again you process is broken since the feed now has the value feeds-1 and not #{Feed}.
I’ve had on my list for some time now to register this bug, hopefully I’ll get around to it now or Octopus staff will pick it up 
Regards,
Jan
Jan thanks for the heads up! Yes hopefully that can get cleaned up quickly… that will be a bit of a training issue I’m sure.
Jan, I entered the bug you found… it was annoying me.
This doesn’t seem to work for me. I’m using v2.3.5.45, and when I specify a variable in the “Nuget feed” text box, and populate it in the variables I get an error when I try to deploy a release:
There was a problem with your request.
- Pre-deployment validation failed: one or more feeds referenced by steps in this project no longer exist. You will need to create a new release.
Hi Lawrence,
Can you please try creating a brand new release and let me know how that goes.
Vanessa
Just to confirm what I have done, the original setting looked like this:
[cid:image001.png@01CFED0D.9A26DE30]
I now have (there is still a bug in the UI where the variable defaults to “feeds-33” when I go on to the edit page:
[cid:image003.png@01CFED0D.EE7C1220]
When I deploy a new release I get the error message:
[cid:image002.png@01CFED0D.9A26DE30]
I have tried this both with the value of the variable set to “Ancillary” and “feeds-33” (the value that the UI defaults to when I go back to the page):
[cid:image004.png@01CFED0D.EE7C1220]
Lawrence
You need to have a default value for your NugetFeed variable. One set without scoping it.
Hi Lawrence,
Thanks for the reply and the screenshots. You mentioned trying the feed name as well as the feed ID - I can confirm that it needs to be the feed ID (so feeds-33 here).
It looks like your variable is scoped to some different fields. Could you try creating a variable that is not scoped (to at least have a default, unscoped value)?
2.3.5 is a fairly old release. I know we fixed the feed display bug recently, and it’s possible this issue has also been fixed. Could you try upgrading to 2.5.11 and let us know if that makes a difference?
Paul
