Have you considered having the ability to use configurable package providers? I imagine some people might want to use SVN, Git, even S/FTP/S to publish their packages. NuGet works fine for my current use cases but I can foresee some of my clients wanting packages in some form of source control or via a secure form of FTP.
I know it misses discoverable meta data but alternatively you could expose SVN revisions or FTP package names as the selection criteria.
Those technologies aren’t mutually exclusive although the way NuGet handles different versions isnt exactly seamless with how different version control systems work.
Given that you can have feeds that are just file system paths, why not offer
sftp -> server which stores them in D:\MyPackages
Then configure Octopus to read from either:
D:\MyPackages if they’re the same server or \FileServer\D$\MyPackages (or similar)
thanks,
Seb
FTP and SVN would be useful when your Octopus is in a network other than your build servers. We are looking at using Octopus to deploy a clients SaaS platform where this environment is completely seperate from the corporate development environments. We would want to reach out (securely) to a build package repository to retrieve the latest packages to install.
It sounds like it might be beneficial for you to have a play with NuGet and NuGet packaging
specifically:
and
managed solutions like http://www.myget.org/Site/Faq
What’s confusing to me is that my (perhaps faulty) assumption that octopus doesn’t need to be local to either your tentacles or your nuget package feeds.
Octopus will consume a nuget feed, which can be served over HTTP. Octopus then in turn communicates the entire package to it’s tentacles, again over HTTP.
From my point of view there’s never an assumption that octopus must be local to either your tentacles or your nuget package feeds.
Nice suggestion gents.
I think it’s beneficial for Octopus to only be aware of one package format, and NuGet seems to make the best trade-off in terms of simplicity and richness. However, I agree that this would be useful. I’m looking at building a custom NuGet server that acts as an “adapter”. It would allow you to connect to:
When triggered it would pull the files from those sources, and package them up into a NuGet package.
As far as Octopus is concerned, the world would still be a lovely, simple place full of NuGet packages. But those packages could be built automatically from a variety of places. I’d like to hear your feedback on this design.
Paul
Sorry I wasn’t suggesting moving away from the package format of NuGet, just supporting more flavours of transport than the NuGet server ATOM? feed, I am not sure on the extact implementation.
I guess I was suggesting transport providers for Octopus so it can retrieve NuGet packages from a variety of sources.
The main driver is better security, especially when reaching out across open networks.
Sebastian, your second post above will have only just shown up in this discussion because Tender marked it as spam and I only just saw it, sorry about that.
You’re right that Octopus can consume a feed from a remote server (over HTTPS) and pushes packages (securely) to Tentacles.
Paul