Automate core tools release (npm, choco, apt) to Azure DevOps Pipelines

[ankitkumarr]

• Add azure-functions-core-tools-3 in apt
• Add azure-functions-core-tools-2 in apt
• Add v3 in chocolatey
• Add Debian 10 package
• Move publish script in this repository
• Remove prompts, and make the scripts automated
• Move this process to be a part of the Azure DevOps release

[ankitkumarr]

As part of this I will also capture the work item to add release pipeline for v3 in chocolatey, apt, etc. Additionally, I will move our publishing scripts to this repository as Ahmed had suggested (@ahmelsayed fyi).

[ankitkumarr]

@jeffhollan / @anthonychu, do you have a preference on core-tools chocolatey package between these installation ways? -

1. choco install azure-functions-core-tools --params "'/version:3'"
2. choco install azure-functions-core-tools --params "'/v3'"
3. choco install azure-functions-core-tools-3

[anthonychu]

Thanks @ankitkumarr. I have limited knowledge of Chocolatey. It looks like its versioning support is not great; there isn't support for installing a tagged version (e.g. @3) or a version range like npm so we can't rely on versioning.

For 1. and 2.:

• What happens if someone runs it without params?
• Would this be a package that contains both v2 and v3? What happens when we release v4? What's the Nuspec version on the package?

Another option we should consider is just release everything under azure-functions-core-tools and tell the user to figure out the latest version of the major version they want; running without a version installs the latest stable. Looks like other packages (Node.js, Helm) on Chocolatey do this. It's not the most friendly thing to document but it's the most consistent with other packages, it seems.

[ankitkumarr]

Thank you Anthony! You are correct about the versioning support (as far as I know).

What happens if someone runs it without params?

Up to us. For backwards compat, I was thinking to let it do what it does today, i.e. install latest v2 (or we can change that to v3). This way everything stays the same, except we also support v3 with this param.

Would this be a package that contains both v2 and v3? What happens when we release v4? What's the Nuspec version on the package?

The way we do nuspec is to only include a powershell script that gets run when installing the package. So, we would only have one powershell file that would download v2 or v3 core-tools from the CDN based on the params.
This is what we do for x64 as well (choco install azure-functions-core-tools --params "'/x64'").

Another option we should consider is just release everything under azure-functions-core-tools and tell the user to figure out the latest version of the major version they want; running without a version installs the latest stable. Looks like other packages (Node.js, Helm) on Chocolatey do this. It's not the most friendly thing to document but it's the most consistent with other packages, it seems.

The user should be able to do this today, except that we haven't release v3 yet for choco.
The one thing that would concern me there is, I think chocolatey would pick the latest version as the default (need to verify).
So, say we came with functions v4, to release core-tools in chocolatey, once we release v4, it'd become the default (which may not be the desired case). Just calling out, as maybe at that point we can just add a prerelease flag or something.

[anthonychu]

I think using a param to select CPU architecture makes sense, as it still installs the version of Core Tools matching the NuGet package version. However, I'm not sure about a param that would install a version different than the package version; that would be surprising to me.

IMO we should go with just releasing new versions on azure-functions-core-tools, it seems par for the course for Chocolatey. I'd also be okay with azure-functions-core-tools-3, and continue updating v2 as azure-functions-core-tools.

I would avoid using parameters to select versions. But would love to hear from more folks who use Chocolatey.

[lbugnion]

Do you have metrics on how many users are installing older versions when a new version is available on npm? My feeling is that there is a number of users who sometimes need to do that, but the majority of users want the easy way to always get the latest. If that's the case, I think that azure-functions-core-tools should always install the latest, and you should provide a path for people who want to target a specific version, for instance azure-functions-core-tools-3

[ankitkumarr]

@lbugnion, I think that makes sense. We don't have metrics as such. But for us, we have two major versions we need to support in chocolatey - v3 and v2. They both are fairly common and we do releases actively.

So, maybe we can have azure-functions-core-tools (always latest), azure-functions-core-tools-2 and azure-functions-core-tools-3. Does that sound reasonable to you, and does that feel natural with chocolatey experience?

[anthonychu]

So, maybe we can have azure-functions-core-tools (always latest), azure-functions-core-tools-2 and azure-functions-core-tools-3. Does that sound reasonable to you, and does that feel natural with chocolatey experience?

Looks like this should work. May depend on outcome of #1898 we can probably at least start publishing azure-functions-core-tools-3 soon.