Publish `netfx` package to assist with deployment of custom packages

[leonio]

Background

When using a custom Calamari NuGet package, it appears that Octopus.Server uses two different NuGet package ids.

• When testing the connectivity of deployment target, it searches for Calamari
• When executing a deployment, it searches for Calamari.netfx

While building out https://github.com/OctopusDeploy/Calamari/pull/688 with @lilwa29 and @miguelelvir we noted that for windows deployment targets, the net40 NuGet package needed to be called Calamari.netfx to successfully deploy a custom version to a local Windows tentacle.

Changes

Have added in an extra build parameter IsCustomPackageBuild for the PowerShell script, and isCustomPackageBuild for the cake build. The cake script will push an extra package for the net40 package (as the runtime id is null). The effect is that the artifacts directory will contain both a Calamari and a Calamari.netfx package to satisfy both connectivity testing, and deployment.

Testing

• spin up test Octo instance from https://octopus.com/docs/installation/octopus-in-container/docker-compose-linux
• configure custom package directory, and upload normal build.ps1 to mapped directory in container
• ensure that connectivity passes, but deploy fails to a locally configured tentacle
• upload packages from build.ps1 -IsCustomPackageBuild:1 and ensure both connectivity test and deploy succeed

[CLAassistant]

All committers have signed the CLA.

[Waldo000000]

Thanks for this contribution @leonio! 🙇 First, I want to give you an update so you're not left waiting here. We would like to take a good look at this PR when time permits, however, I don't currently have a timeframe to share with you on this. It could be quite some time before we give you more details.

We are currently reviewing our guidance and process for external contributions, to make these expectations clearer upfront. Again, thanks for the contribution and I'm sorry I couldn't give you a quick turnaround with specific advice in this case.

[Waldo000000]

In the meantime @leonio, if you're blocked or need assistance for your use case, you can follow our support guidelines to get help from our support team, who can probably help to find a workaround or make sure the issue gets prioritized properly 🙏

[leonio]

Thanks for this contribution @leonio! 🙇 First, I want to give you an update so you're not left waiting here. We would like to take a good look at this PR when time permits, however, I don't currently have a timeframe to share with you on this. It could be quite some time before we give you more details.

We are currently reviewing our guidance and process for external contributions, to make these expectations clearer upfront. Again, thanks for the contribution and I'm sorry I couldn't give you a quick turnaround with specific advice in this case.

Thanks for the reply @Waldo000000 - no worries on the timeframe for now, we're running this locally to ensure the Calamari.netfx package is built for the required timeout functionality. Look forward to any feedback, and hopefully seeing how this and #688 can merged in the future. 👍

[johnsimons]

@leonio I think we can now close this PR based on https://github.com/OctopusDeploy/Calamari/pull/688#issuecomment-765003121, are you happy with me closing it?

[leonio]

@johnsimons I still think this could still be an issue for anyone trying to use customBundledPackageDirectory via these config options.

I've used the repro steps above, and by spinning up a new instance, using a custom bundle directory, and configuring a local tentacle I still get the follow error.

By using the additional build parameter which duplicates the net40 package, with the netfx moniker, the output from the build script can be used in a custom bundle directory.

No worries if you'd prefer to close this and handle it via another method (e.g. the server sends a local version if none is configured in the custom module directory). In a way. it's related to the same issue with Calamari.AzureScripting package. When it's not found in the custom modules directory, there is no way for it to fall back to what the server would normally send to a tentacle.

Thanks again for all the support and feedback with these PR's.

/cc @miguelelvir