Support OctoPack

[jrnail23]

I'm thinking this would be done via extensions to the existing MSBuild settings & fluent interface DSL, as it just involves adding OctoPack-specific properties to your MSBuild command.

http://docs.octopusdeploy.com/display/OD/Using+OctoPack

[RichiCoder1]

Something like?:

Task("Package")
    .Description("Package the website for Octopus")
    .Does(() =>
{
    MSBuild("./Dashboard.sln", settings =>
        settings
            .SetConfiguration(configuration)
            .WithTarget("Build")
            .RunOctoPack()
            .PublishPackageToHttp("http://my.server.com/api/v2")
            .PublishApiKey("903840932840spsda-sdasdasdas"));
});

[gep13]

Sounds like a great addition to me 👍

[jrnail23]

@RichiCoder1, yeah, something like that, although there are several options and properties that can be set, so that might merit its own OctoPackSettings object and DSL builders.

[patriksvensson]

@jrnail23 @RichiCoder1 Sounds good to me.

So something like this then?

Task("Package")
    .Description("Package the website for Octopus")
    .Does(() =>
{
    MSBuild("./Dashboard.sln", settings =>
        settings
            .SetConfiguration(configuration)
            .WithTarget("Build")
            .WithOctoPack(new OctoPackSettings()
                 .SomeOctoPackThing()
                 .SomeOtherOctoPackThing());
});

[jrnail23]

@patriksvensson, yeah, that's pretty much what I was thinking 😄

[arri-cc]

Is anyone working on this issue? If not I would like to help get it done

[gep13]

@arri-cc I don't think anyone in the core team is looking at this yet, so unless @jrnail23 is currently looking at this, I would suggest that it is up for grabs. Were you thinking about doing this as an Addin for Cake, or as a contribution into Cake directly?

[arri-cc]

@gep13 I think targeting an enhancement in either Cake.Common.Tools.MSBuild or Cake.Common.Tools.OctopusDeploy so that would be direct right? Are there any rules regarding dependencies between tools?

[patriksvensson]

@arri-cc Would prefer if this was solved without involving MSBuild. Preferably this would be a wrapper around Octo.exe

[RichiCoder1]

OctoPack is literally an msbuild intergration :). That being said, an Octo tool wrapper would be cool too.

[patriksvensson]

@RichiCoder1 Yes I know. Was more thinking about what I would prefer :) As long as stuff doesn't touch the MSBuild tools in any way and is done by extension methods I'm fine with that as well.

[gep13]

For what is worth, my immediate thoughts were an addin around octo.exe, with some extension methods for the additional MSBuild arguments of packing NuGet packages, etc.

[arri-cc]

@gep13 An add-in octo.exe wrapper makes sense. I just came across this gap last night when I started using Cake on a project, so I'm still coming up to speed with how this is architected. I'll do some research and come back with some ideas to pitch.

[gep13]

@arri-cc perfect! Feel free to have a look at this: https://github.com/gep13/Cake.ReSharperReports as an example of how to create an addin.

[cpx86]

I've started to look into this. Here is my suggestion so far.

octo pack takes the following arguments:

Basic options:

      --id=VALUE             The ID of the package; e.g. MyCompany.MyApp
      --format=VALUE         Package format. Options are: NuPkg, Zip.
                             Defaults to NuPkg, though we recommend Zip going
                             forward.
      --version=VALUE        [Optional] The version of the package; must be a
                             valid SemVer; defaults to a timestamp-based
                             version
      --outFolder=VALUE      [Optional] The folder into which the generated
                             NUPKG file will be written; defaults to '.'
      --basePath=VALUE       [Optional] The root folder containing files and
                             folders to pack; defaults to '.'

NuGet packages:

      --author=VALUE         [Optional, Multiple] Add an author to the
                             package metadata; defaults to the current user
      --title=VALUE          [Optional] The title of the package
      --description=VALUE    [Optional] A description of the package;
                             defaults to a generic description
      --releaseNotes=VALUE   [Optional] Release notes for this version of the
                             package
      --releaseNotesFile=VALUE
                             [Optional] A file containing release notes for
                             this version of the package

Advanced options:

      --include=VALUE        [Optional, Multiple] Add a file pattern to
                             include, relative to the base path e.g. /bin/-
                             *.dll - if none are specified, defaults to **
      --overwrite            [Optional] Allow an existing package file of the
                             same ID/version to be overwritten

This can be quite nicely built in the same style as the existing OctoCreateRelease and OctoPush methods:

Task("Package")
    .Description("Packages the project")
    .Does(() =>
    {
        OctoPack("MyPackage", new OctopusPackSettings
        {
            Format = OctopusPackFormat.NuPkg, // or OctopusPackFormat.Zip
            Version = "1.2.3",
            OutFolder = "./octopacked/",
            BasePath = "./",
            Author = "someone",
            Description = "my sweet package",
            ReleaseNotes = "good stuff was built",
            ReleaseNotesFile = "releasenotes.md",
            Include = new[]
            {
                "bin/*.dll",
                "css/*",
                "js/*"
            },
            Overwrite = true,
        });

Thoughts?

[gep13]

@cpx looks good to me. Which, if any of those properties are mandatory? All mandatory parameters should be into arguments to the alias, not contained within the Settings class.

[cpx86]

@gep13 Only the package ID is mandatory.

Another aspect is that author, description and release notes are only valid if the format is NuPkg. Should the tool have any special handling if you provide any of them for Zip packages? Throw exception? Or just let octo handle it? I'm not sure what the convention is here.

[gep13]

@cpx ok, good to know.

With regard to the parameters, and when they used be used.... Does Octo handle the situation when parameters are passed in when they aren't required? If so, I think it would be safer just to let it handle the issues, rather than trying to replicate the issue in the addin. The thought process being that if octo, for some reason changes in a future release, we would need to update the logic as well, which feels wrong to me.

[cpx86]

@gep13 Just tried out a few combos and octo ignores the NuGet-specific parameters when creating a Zip-package. As you say, this behavior could change in the future, so adding parameter validation to Cake that octo doesn't currently care about also feels wrong to me. Should we then stick to only validating the package ID parameter? That one seems unlikely to become optional.

[agc93]

Now we've got another Octopus tool with another set of parameter questions probably means we should revisit #1022 as well..

[cpx86]

@agc93 Yeah I was thinking the same while I was implementing this. Pack is a bit special though, since it doesn't interact with the server it doesn't take apiKey or server parameters.

[patriksvensson]

Merged via #1218.

[nimendra]

Hi,

 Include = new[]
            {
                "bin/*.dll",
                "css/*",
                "js/*"
            },

doesnt work for me -

System.InvalidOperationException: Cannot create a package that has no dependencies nor content.

If I use specific paths, instead of bin/* it does create the nupkg.
Any ideas? Thanks

[patriksvensson]

@nimendra It would be better if you created a new issue or reached out in our Gitter channel than posting on a closed issue. Makes it impossible to track potential fixes over releases. Thanks!