Currently we use an external NuGet file feed on a separate storage appliance to store our packages, and are doing so as NuGet files.
With the deprecation of the Azure DevOps task for creating NuGet packages, I’m looking at the suggested alternative of using the Archive Files task to create a ZIP package. However, these are not compatible with external feeds.
The obvious move would be to just use the pack command on the Octopus CLI; but with the task being deprecated, I’m afraid that that might going away too.
Are there plans to deprecate/remove the pack command from Octopus CLI, or is it just the task that’s going away and we can rely on using the CLI task in the long term?
Hey there Andrew! Yes, the plan is to completely remove pack from the CLI, however, I do not know when it will be removed. The nuget.exe CLI contains a pack command that you can use as a replacement for the octo pack functionality for creating NuGet packages. Does your storage appliance support use of Maven feeds? If so, you could store the .zip files within a Maven feed and deploy it that way.
Hope this helps!
No, all we have are file folders accessible via SMB.
NuGet CLI’s pack command won’t work out of the box. I can’t run it against the .csproj because we need to include files in the package that aren’t referenced by the project (e.g. custom Deploy.ps1 scripts). (Even if I could, the package ID we use and the name of the csproj might not match up.)
How does Octopus use the nuspec file in NuGet packages? Using nuget spec to initialize a file in our build pipeline adds a bunch of “example” stuff to the file compared to ones generated by the Octopus CLI. Most of this is probably ignored by Octopus, but the <dependencies /> section worries me, as does the license information (more from a legal perspective than a deployment perspective). And editing a nuspec file ourselves within the build pipeline is hard.
<license type="expression">MIT</license>
<licenseUrl>https://licenses.nuget.org/MIT</licenseUrl>
<projectUrl>http://project_url_here_or_delete_this_line/</projectUrl>
<description>Package description</description>
<releaseNotes>Summary of changes made in this release of the package.</releaseNotes>
<copyright></copyright>
<tags>Tag1 Tag2</tags>
<dependencies>
<group targetFramework=".NETStandard2.1">
<dependency id="SampleDependency" version="1.0.0" />
</group>
</dependencies>
Octopus doesn’t do a restore action on a NuGet package like a build server would. Octopus treats a NuGet package similar to a .zip file in that it uses it purely as an archive of files that need to be extracted. It expects all files that are necessary for deployment to be present within the package itself.
When using octo pack to create a NuGet package without specifying a .nuspec file, the CLI generates a .nuspect file similar to the following
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
<metadata>
<id>carrental.web</id>
<version>1.1.0</version>
<authors>Shawn.Sesna@PRECISION5530</authors>
<owners>Shawn.Sesna@PRECISION5530</owners>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<description>A deployment package created from files on disk.</description>
</metadata>
</package>
The information is quite minimal. If you place a file similar to this in the output folder of your build, you can run something like nuget pack c:\github\carrental\src\carrental.web.nuspec -BasePath c:\github\carrental\src -OutputDirectory c:\temp and produce a NuGet package that you can store on your SMB share.
Does this help?
Regards,
Shawn