Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Support .zip and .tar.gz package formats #2183
A goal for Octopus in 2016 is this idea of Octopus Everywhere. Any application you might want to deploy, any target environment - Octopus should have a great (if opinionated) way to do it. PowerShell in deployments should happen less and less.
If we want to achieve this, something we need to address is packaging apps - NuGet just isn't going to work. We've written previously about the need for a packaging format designed specifically for applications, and it's time to take a leap.
Historically Octopus has required NuGet. This was a pragmatic choice made because of the ecosystem around NuGet (and Octopus being .NET focussed). NuGet provided us with:
The NuGet package format isn't particularly valuable; the real value is the repository protocol. Tools like TeamCity, VS Online, MyGet, Artifactory, Nexus and other repositories supporting the NuGet protocol, so it makes sense for Octopus to simply work with them.
However, NuGet also provides some challenges:
So we first must teach people about creating
With ASP.NET 5 switching from MSBuild-based builds to command-line tools, the ways that we plugged in to produce NuGet packages need to be revised. Octopus is also starting to be used to deploy more than just .NET applications. We have a few options:
Since Octopus server comes with a built-in package repository, we'll extend this to support:
From a metadata point of view, there's only two pieces of metadata we need from every package:
So the convention would be to simply name the archive:
Since the ID can include dots, the version is assumed to start the first time we encounter a segment with just a number. E.g.,
The version starts at 11 because it is the first numerical segment.
If we ever need to supply further metadata in the future, we could do this based on the contents of the package - either with an Octopus metadata file, or some conventions (e.g., release notes might be in a file called CHANGELOG).
Builds from languages other than .NET would be greatly simplified. When building a Node.js app, for example, your Gulp/Grunt tasks would just have to:
If we ever added
Changes we'd need to make
I'd envision that the packages would flow through Octopus/Calamari as-is; we wouldn't try and convert them to/from other formats.
Here's a stab at the regex:
var regex = new Regex(@" ^(?<id>[\w\.]*?)\. (?<semver> (?<major>0|[1-9][0-9]*)\. (?<minor>0|[1-9][0-9]*) (\.(?<patch>0|[1-9][0-9]*))? (?<pre>-[\da-z\-]+(?:\.[\da-z-]+)*)? (?<meta>\+[\da-z\-]+(?:\.[\da-z\-]+)*)? ) (?<ext>\.tar\.gz|\.tgz|\.zip|\.nupkg) $", RegexOptions.IgnoreCase | RegexOptions.Compiled | RegexOptions.Singleline | RegexOptions.IgnorePatternWhitespace);
I also agree that we avoid transformation into some intermediary/common package format. Allowing packages to pass-through as-is will be less complicated, and we can cater for that at the point of extraction. I think people will encounter less surprises using this approach.
Documentation started at
@klh this ticket has already been closed for some time as support for zips & tars has been in Octopus Deploy since 3.3.