Include binaries when calling Octopack target in isolation

Legacy Execution
1

This concerns OctoPack 3.6.1 (the NuGet package).

We use Gitlab-ci to run CI in several stages: build, test, pack, publish (etc). What we’d like to do is build our projects in one stage, then pack the binaries that are produced in a separate stage. To that end we’re using /t:OctoPack /p:RunOctoPack=True rather than /t:Build /p:RunOctoPack=True.

Specifically, the MSBuild target we’re using to build a selection of C# project files is

  <Target Name="Pack-WebDeploy-OctoPack" DependsOnTargets="SelectWebDeployProjects; InjectOctoPackTargets">
    <Message Text="Packaging %(TargetProjectFiles.Filename) for Octopus deploy" Importance="High" />
    <Error
      Text="No Web Deploy projects detected! Make sure your project is named 'Wayfair.[team].Service.[name], or use the 'IncludeProjects' property.'"
      Condition="'@(TargetProjectFiles)' == ''"/>
    <Exec
      Command="MSBuild @(TargetProjectFiles) ^
              /Target:OctoPack ^
              /Property:RunOctoPack=True ^
              /Property:Configuration=$(Configuration) ^
              /Property:OctoPackUseProductVersion=True ^
              /Property:OctoPackEnforceAddingFiles=True ^
              /Property:OctoPackPublishPackageToFileShare=%(TargetProjectFiles.RelativeDir) ^
              /MaxCPUCount /NodeReuse:False"
      IgnoreExitCode="False"
    />
  </Target>

This command works as expected - a nuspec file is generated and Octopack produces a .nupkg in the output folder indicated by OctoPackPublishPackageToFileShare - with one exception: no binaries are included in the package.

The structure of the package as created:

package/services/metadata/core-properties/[yada].psmdcp
Properties/SlowCheetah/SlowCheetah.Transforms.targets*
_rels/.rels
favicon.ico
Global.asax
log4net.config
Wayfair.Pricing.Service.LipService.nuspec
Web.config
Web.Debug.config
Web.Release.config
[Content_Types].xml

(in otherwords, a fairly normal package for a web deploy project, minus all of the binaries)

I’ve verified that the binaries are in fact present in bin\Release when this target is called (which matches $(Configuration), although we’ve also verified that behavior doesn’t change when this is hardcoded). I’ve tried builds with OctoPackEnforceAddingFiles set to true, false, and not included at all.

I’ve also tried adding the binaries to the FileWrites itemgroup (see https://msdn.microsoft.com/en-us/magazine/dd419659.aspx) since that appears to be where the target (https://github.com/OctopusDeploy/OctoPack/blob/master/source/build/OctoPack.targets) acquires the list of files to pass into CreateOctoPackPackage (https://github.com/OctopusDeploy/OctoPack/blob/master/source/OctoPack.Tasks/CreateOctoPackPackage.cs).

What I’d like is the ability to direct the OctoPack target to pick up the binaries that were produced by a previous build. I would like to avoid editing individual project files in order to do so, since I am building targets that will be used by a repository containing dozens of projects.

*Transforms happening during the build or within Octopus is immaterial to us at this point (we’re going to have to support both eventually, since some of our projects use preprocessor directives aimed at build configurations)

2

Hi,

Thanks for reaching out. Octopack was really designed to run along MSBuild, as it uses its output and the project file to smartly recognize which files it is supposed to package. I’m afraid that decoupling it like this is not gonna by an easy task at all (if its even possible).

Have you tried using something like Nuget.exe pack or Octo.exe pack for the packaging step? You’ll need to point them to the directory where MSBuild outputs everything (bin\release)

Regards,
Dalmiro

3

Yes, we can easily use either mechanism to pack the project (and are currently doing so for non-Web Deploy projects). I just figured that using OctoPack’s target would provide better integration with Octopus Deploy.

4

What’s the behavior of Octo.exe regarding transforms? Using that CLI might still provide some benefit over NuGet for us.

5

Hi,

I just figured that using OctoPack’s target would provide better integration with Octopus Deploy.

Octopus really doesn’t care how the package was created, as long as it is within the accepted formats (nupkg, zip, tar).

What’s the behavior of Octo.exe regarding transforms? Using that CLI might still provide some benefit over NuGet for us.

Neither Octo.exe or Nuget.exe do anything with transforms. They’ll simply pack whatever you tell them to pack. To these tools the transform files are simply another file that has to be packed.