We’re using Octopack to generate a NuGet package that we can deploy via Octopus to an Azure Function App. However, the generated NuGet package doesn’t contain the required
Looking in to the logs, it seems that the
Octopack target is running before the
_GenerateFunctionsPostBuild target, meaning that the Function folder containing
function.json hasn’t yet been created when my NuGet package is generated.
_GenerateFunctionsPostBuild target can be found in the microsoft.net.sdk.functions NuGet package -
<Target Name="_GenerateFunctionsPostBuild" AfterTargets="Build">...</Target>
Octopus target can be found in Octopack.targets, and unfortunately there is no
AfterTargets parameter that can be passed via command line -
<Target Name="OctoPack" Condition="$(RunOctoPack)">...</Target>
In lieu of being able to specify an
AfterTargets parameter, how can I make it so that Octopus runs last of all?
Please find below an excerpt from my logs that shows the target order.
|build|06-Apr-2018 15:25:52| OctoPack: Get version info from assembly: C:\build\CHBGS-BHBGS3-JOB1\AzureFunction\bin\Release\net461\bin\AzureFunction.dll|
|build|06-Apr-2018 15:25:52| Using package version: 1.0.6-CSGCS-2377-hmlr-build|
|build|06-Apr-2018 15:25:52| OctoPack: OctoPack version: 18.104.22.168|
|build|06-Apr-2018 15:25:52| OctoPack: Written files: 193|
|build|06-Apr-2018 15:25:52| OctoPack: Copy file: C:\build\CHBGS-BHBGS3-JOB1\AzureFunction\AzureFunction.nuspec|
|build|06-Apr-2018 15:25:52| OctoPack: Files will not be added because the NuSpec file already contains a <files /> section with one or more elements and option OctoPackEnforceAddingFiles was not specified.|
|build|06-Apr-2018 15:25:52| OctoPack: NuGet Version: 22.214.171.124733 (Custom build for OctoPack. See http://g.octopushq.com/VersioningInOctopusDeploy)|
|build|06-Apr-2018 15:25:52| OctoPack: Attempting to build package from 'AzureFunction.nuspec'.|
|build|06-Apr-2018 15:25:53| OctoPack: Successfully created package 'C:\build\CHBGS-BHBGS3-JOB1\AzureFunction\obj\octopacked\AzureFunction.1.0.6-CSGCS-2377-hmlr-build.nupkg'.|
|build|06-Apr-2018 15:25:53| OctoPack: Copy file: C:\build\CHBGS-BHBGS3-JOB1\AzureFunction\obj\octopacked\AzureFunction.1.0.6-CSGCS-2377-hmlr-build.nupkg|
|build|06-Apr-2018 15:25:53| OctoPack: Packaging finished successfully|
|build|06-Apr-2018 15:25:53| Directory "C:\build\CHBGS-BHBGS3-JOB1\AzureFunction\bin\Release\net461\refs" doesn't exist. Skipping.|
|build|06-Apr-2018 15:25:53| Moving file from "C:\build\CHBGS-BHBGS3-JOB1\AzureFunction\bin\Release\net461\AzureFunction.pdb" to "C:\build\CHBGS-BHBGS3-JOB1\AzureFunction\bin\Release\net461\bin\AzureFunction.pdb".|
Thanks for getting in touch!
Can you try adding
_GenerateFunctionsPostBuild and see if that does the trick? It should look like this:
<Target Name="_GenerateFunctionsPostBuild" AfterTargets="Build" BeforeTargets="Octopack">...</Target>
Let me know if that works for your setup.
_GenerateFunctionsPostBuild comes from a NuGet package Microsoft.NET.Sdk.Functions, so unfortunately I cannot make any changes to it.
Hopefully I’m missing something somewhere else, but if not I do a have a workaround. Currently I’ve stopped using OctoPack and I’m creating the NuGet package manually after the build task has finished.
If the workaround is the only solution here, how would I go about making a feature request for future versions? It would be great if there was a parameter
AfterTargets that I could use to ensure OctoPack runs exactly when it’s required.
Before we dwelve into the workaround, is there any chance you can send me your project’s
.csproj file so I can take a look at it and try a few things?
If you don’t want to share the file publicly here, you can upload it to the below link which only our staff has access to
I’ve uploaded privatly via the link that you provided.
Thanks for sending that file over. In this case the workaround is going to have to be the actual solution.
Octopack works really well for very straightforward projects where all you have to do is compile 1 project and pack it. But as soon as you have to do something extra like its your case where you need to compile/run something extra and include its results in the package,
Octopack falls a bit short, reason why we don’t recommend to use it too much these days.
The process we recommend goes along these lines:
Compile your project without
Octopack and send the output to a folder. This folder should have everything that you need to get into your package.
Run a command line tool to Pack the contents of that folder and then Push it to a repository. For this we recommend you to use Octo.exe pack and Octo.exe push. The latter command will only work if you are pushing packages to the Octopus built-in repository. If you are not using that one, you’ll need to push the package with something else like
- How would I go about making a feature request for future versions?
The recommended channel for these type of requests is our uservoice page. That said, unless the feature request gets a very big amount of votes, its a bit unlikely we’ll keep adding features to
Octopack going forward. As I mention previously,
Octopack falls a bit short in a couple of real common scenarios like yours. And while that is definitely fixable, the biggest problem with
Octopack is that its tied exclusively to .NET 4.X projects, leaving .NET core, Node, Java and all the other kinds of projects outside of its scope. For this reason we are putting a lot of effort into building
Octo.exe push/pack, which can be added to any build pipeline pretty easily regardless of the build server you are using or the project type you are building.
I know its not the answer you were looking for, but hopefully It’ll help you understand a bit more of the background behind these tools.
Let me know if you have any kind of questions about this
Thanks for the in-depth explanation. Your’re right that it’s not exactly the answer I’m looking for, but at least there is the workaround, which isn’t really much trouble to implement.
I this case we’re using a NuSpec file to package and pushing to MyGet, so I’m having to use
nuget.exe as opposed to
In the future, we plan to use Zip files as opposed NuGet packages, so
octo.exe will become more appropriate. At this time though, I don’t believe that Octopus supports any 3rd party Zip repositories (it’s been a while since I checked though), so we’re stuck with NuGet/MyGet.
Thanks again for your assistence.
The use of
Nuget.exe in your case makes total sense. Is there any chance you can drop by the below Uservoice sugestion and add some votes to it? The goal of it is to add support for
Apologies for the slow reply. I’ve added my votes to the Uservoice in you post, so fingers crossed it gets picked up soon.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.