NPM and Bower package support
It would be great if Octopus would also support external NPM and Bower feeds instead of NuGet or the internal Octopus feed.
Background:
Octopus does a great job when deploying Windows software based on NuGet packages. As described in #2183 the NuGet package format isn't always suitable. Octopus now supports to store arbitrary archives in the internal Octopus feed. Although this might be useful in some cases, you don't want Octopus to become a package repository. Octopus can also fetch from TeamCity, but TeamCity is also limited to a NuGet only feed and should be responsible to build software, not to host it.
I think that neither TeamCity nor Octopus should be used as package repositories for large scale applications. There are numerous good alternatives (like MyGet or ProGet) that are specialized in hosting package repositories.
Octopus can connect to such a repository for NuGet packages, but this is rather limited. Creating NuGet packages on non-Windows platforms in cumbersome, but it's very easy to create a Bower or NPM package. If Octopus could fetch from NPM or Bower feeds, then these packages could be consumed in much more natural way.
Both package systems use a similar versioning scheme as NuGet and also supply meta information that is needed by Octopus for discovery of packages and their versions. Then you could use the following paradigm that uses proper separation of concerns:
- TeamCity: Builds software
- Octopus: Deploy software
- Proget: Store artifacts
Ramon de Klein
shared this idea
-
Darrell Tunnell
commented
In addition to the feed types mentioned, proget's "universal format" feed offers a basic zip format feed, and cross platform cli, and I think it would be great if octopus could support that: https://inedo.com/upack
-
Cristian Prieto
commented
@admin:
Yes, this is actually a good idea, fixing the "package" content as just a simple zip file. A needed plugin would need then only two important endpoints:
- The content of the "package" as zip file
- The list of versions and package metadata (so the versions can be selected for deployment)Things like Maven, Bower, NPM, Ivy and even GitHub and Artifactory (or Bintray) support an API to query about available versions for an artefact, this will make everything easier as an implementor to just query and show you a list of available packages and versions and then when needed just retrieve those versions.
Thanks a lot for listening to our cry Octopus, in the past I had to deal writing our own "Octopack" gulp plugin (before you released your version) and now a Gradle plugin to package our artefacts.
-
@Christian There are some downstream issues with being able to extract packages on the tentacle/SSH side. Our extensible model does not (yet) reach that side of the system.
What if we added the ability to add a plugin for a particular feed type (eg NPM, Artifactory) and the plug in returned a Zip compatible file (repacking it if the original is not).
Is there anything in these package formats that would be useful after it is retrieved from the feed?
-
Cristian Prieto
commented
I actually will prefer the versioning and packaging retrieval to be extensible so we can use our own abilities if needed.
We won't have to wait until Octopus decided to implement a specific repository type to use it (as it happened with Docker). Think about package repositories in the same way a CI system handles SCM, it is at the end the source of what you need to do and every system has their own quirks so CI systems mostly use an extension point for this.
Zip files are a good example of this, while current implementation uses the "version" as part of the name I see cases (which are already a "sort of standard" in other platforms), a good example, Ivy.
I will be happy to discuss this further if more information is needed.
