bazelbuild / bazelbuild/bazel

Integrate chocolatey package publishing into release process

Open
#4,049 10 comments 0 reactions 0 assignees View on GitHub
area-EngProd not stale P2 team-OSS type: feature request
Dominant language
Java
Stars
25.8k
Forks
4.6k
Avg merge
2d 20h
Merged PRs (30d)
72

Description

### Description of the problem / feature request / question:

At present, publishing the chocolatey package for Windows is a manual process

0. hear about an RC or release
0. run (on Windows)
```powershell
pushd "scripts/packages/chocolatey"
./build.ps1 -version -mode -rc
./test.ps1 -version
& choco.exe push # this assumes the secret for the chocolatey API key is present in the user's profile
popd
```
0. reply to the release ticket saying that the package has been pushed and the URL it's available from.

I'd like to eliminate this manual process from the release.

#### Dependencies:
0. choco.exe - binary only available for Windows, but [apparently choco.exe can be compiled and run on Linux](https://github.com/chocolatey/choco#other-platforms). So, try that out.
0. chocolatey API key secret - bazel team should sign up to chocolatey and I'll invite that account to become a package maintainer
0. sha256 of the bazel zip file that the chocolatey package downloads and installs - so, access to either that file, or the release binaries directly to calculate that.
0. actually verifying that the package installs on Windows

Having talked to @damienmg and @dslomov the simplest thing to do is to create a Dockerfile for a (ubuntu, probably) container that contains
* the choco binary
* the packaging script
* the API key secret
* the build output

and then runs the steps (probably, rewritten into bash) to publish the package.

So, I'll have a go at this.

I need to know where to put what I create - I'm going to assume within bazelbuild/continuous-integration somewhere?

Also note dependency (4) - this approach does not satisfy that requirement. Doing that would, I suppose, require shifting this left to become an artifact that is built and tested within CI, as opposed to just within the release process.

I don't intend to address that within this work. Sounds like to do so we'd want to create some `pkg_chocolatey` rule akin to [deb and rpm](https://docs.bazel.build/versions/master/be/pkg.html).

Contributor guide

Open the contributing guide

Research direction

Start with scripts/packages/chocolatey/build.ps1 and scripts/packages/chocolatey/test.ps1, then inspect the bazelbuild/continuous-integration area where the automation may belong. Determine how the release process exposes the Bazel ZIP and secrets, and how a container can run the packaging and publish steps. Done means Chocolatey publishing no longer requires the listed manual Windows commands; Windows installation verification is explicitly out of scope.

Written by the indexing model from the issue text.

Assessment

Tech stack
bash, docker, powershell
Domain
build-system, ci-cd, devops, release
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.