ci: add Chocolatey support

[phorcys420]

Hello all, I'm finally contributing Chocolatey building (#3714) to the project long after I said I would do it.

This is a draft because there are some questions that need to be answered by the team:

1. should copyright be uncommented ? (L26 of coder.nuspec) (I think it should be removed since this is the community edition right ?
2. should requireLicenseAcceptance be uncommented ? (L28 of coder.nuspec)
3. someone from the coder team (cc: @bpmct) needs to create an account @ https://community.chocolatey.org and define the CHOCO_API_KEY GH secret with the API key.

Other than that, I have tested all the PowerShell code in PS v7 and it works like intended (except for choco push).
I could not get the GH action to run in my repository, so that's the only thing I see that might cause issues, because the action itself was not tested. @matifali recommended that I don't bother trying to get the action running in my own repo, so here I am!

---

Now that I'm looking at this, there is another question I would like asking, does the winget job actually need to checkout and fetch tags ? from what I see it doesn't actually need the repo to be cloned at all.

[deansheather]

Now that I'm looking at this, there is another question I would like asking, does the winget job actually need to checkout and fetch tags ? from what I see it doesn't actually need the repo to be cloned at all.

You're probably right.

[deansheather]

1. should copyright be uncommented ? (L26 of coder.nuspec) (I think it should be removed since this is the community edition right ?

The binaries we ship include enterprise code. We don't ship AGPL binaries and don't plan to. The enterprise binaries will not use enterprise features without a valid license. This should probably be uncommented

2. should requireLicenseAcceptance be uncommented ? (L28 of coder.nuspec)

Yes, probably. With both the enterprise license and AGPL license shown if possible

[phorcys420]

With both the enterprise license and AGPL license shown if possible

It seems that the nuspec only accepts one licenseUrl
I think what we can do though is expose a LICENSE.mixed at the root of the repo or on coder.com

Also, should this use slim binaries instead ?

[deansheather]

It seems that the nuspec only accepts one licenseUrl
I think what we can do though is expose a LICENSE.mixed at the root of the repo or on coder.com

I guess? @bpmct

[deansheather]

Also, should this use slim binaries instead ?

No this should be fat binaries from GitHub releases. We don't ship slim binaries except for use in agents and our vscode extension

[phorcys420]

I have applied your modifications and I am waiting for @bpmct's input on the license thing.

Should I squash the license change into the "ci: add Chocolatey manifest" commit or simply create another commit ?

[deansheather]

LGTM, we just need Ben or someone else to add API keys and comment on the license thing

[bpmct]

It seems that the nuspec only accepts one licenseUrl
I think what we can do though is expose a LICENSE.mixed at the root of the repo or on coder.com

I guess? @bpmct

I'm in favor of a LICENSE.mixed. We're submitting to other package manager things such as AWS Marketplace and they also only support a single license URL.

Edit: this does not seem that common. Let's link to the enterprise license instead since that is what we distribute.

[bpmct]

We set CHOCO_API_KEY as a GitHub actions secret 👍🏼

[phorcys420]

Edit: this does not seem that common.

Yes but I think it also makes sense given that multi-licensing is not so common, and maybe they don't use the name "LICENSE.mixed", that was simply a suggestion.

Let's link to the enterprise license instead since that is what we distribute.
Well, we do distribute both licences in the zips and the installer even creates its own mixed license.

I think it would make sense to follow this behavior since we're already doing it with the rest.
It will also be an issue with scoop since it also accepts a single license and it wouldn't make sense that all of the packages that can only accept a single license combine the license themselves like the installer does, it would be redundant.

[matifali]

@phorcys420, is it ready for merging?

[phorcys420]

@matifali I was still waiting for Ben because I think we should really use the dual license.
But I just realized that I can simply set the enterprise license for now and change it later.

I will change the license right now.

[phorcys420]

sorry, had to force-push because I am not used to git yet and merged the main branch on accident.

[matifali]

Let's merge it. :)