Release process automation

[rtibbles]

Summary

• Modularizes some previous asset handling Javascript
• Implements release process automation when a new release is published on the Kolibri repo
• Builds all assets
• Builds the DMG with the release flag set to true so that it builds a codesigned DMG
• Does an upload to testpypi of the whl and tar.gz files
• Specifies a release environment that requires manual approval before proceeding to later jobs
• Uploads to pypi, dependent on the manual verification step
• Uploads to the release assets page, dependent on the manual verification step
• Uploads to Google Cloud Storage, dependent on the manual verification step

Reviewer guidance

This is a work in progress and will not currently function.

Things currently missing:

• [ ] Setting up all needed secrets on the Kolibri repo, including:
  • [x] PyPi token
  • [x] Test PyPi token
  • [ ] a GPG signing private key and passphrase
  • [x] Secrets for GCS Bucket and credentials
• [x] It's possible that the secrets will need to be passed into the PyPi upload workflow, as it is being invoked using workflow call
• [x] The windows installer is not currently being signed, that pipeline needs a release flag added and code signing functionality included

Is there anything else I've missed?

---

Testing checklist

• [ ] Contributor has fully tested the PR manually
• [ ] If there are any front-end changes, before/after screenshots are included
• [ ] Critical user journeys are covered by Gherkin stories
• [ ] Critical and brittle code paths are covered by unit tests

PR process

• [ ] PR has the correct target branch and milestone
• [ ] PR has 'needs review' or 'work-in-progress' label
• [ ] If PR is ready for review, a reviewer has been added. (Don't use 'Assignees')
• [ ] If this is an important user-facing change, PR or related issue has a 'changelog' label
• [ ] If this includes an internal dependency change, a link to the diff is provided

Reviewer checklist

• Automated test coverage is satisfactory
• PR is fully functional
• PR has been tested for accessibility regressions
• External dependency files were updated if necessary (yarn and pip)
• Documentation is updated
• Contributor is in AUTHORS.md

[rtibbles]

Is that a Github feature in the repo settings or something that'd need to be committed?

It's a Github feature - we have organization level secrets that we can let certain repositories access. This means that we don't have to commit them to the repo (++good), and that their values are explicitly hidden in the Github Actions logs.

[github-actions[bot]]

Build Artifacts

Asset type	Download link
PEX file	kolibri-0.16.0.dev0_git.20221018204420.pex
Unsigned Windows installer	kolibri-0.16.0.dev0+git.20221018204420-unsigned.exe
Debian Package	kolibri_0.16.0.dev0+git.20221018204420-0ubuntu1_all.deb
Mac Installer (DMG)	kolibri-0.16.0.dev0+git.20221018204420-0.3.0.dmg
Source Tarball	kolibri-0.16.0.dev0+git.20221018204420.tar.gz
WHL file	kolibri-0.16.0.dev0+git.20221018204420-py2.py3-none-any.whl

[DXCanas]

• PyPi token
• Test PyPi token

Given that we're doing something similar for other packages, seems like we should bubble these up to the org and use them here too?

a GPG signing private key and passphrase

Jose went through the trouble of demoing how to sign debs with me and I never used that training after the first and only time I made a release over a year ago. He would probably be best suited to consult here?

Secrets for GCS Bucket and credentials

Is this for le-downloads/the download page on the site? Or for the BCK uploads? Either way, I recently went through the automation process here and can definitely assist here; would most likely be a service acct JSON blob. Would be hard to imagine there's not action for this already.

The windows installer is not currently being signed, that pipeline needs a release flag added and code signing functionality included

After getting a little more familiar with this recently, I don't think it'd be a huge challenge. All the docs online insist on adding the creds to the sort of "keychain" concept that Windows encrypts and stores away in fancy hardware. But the signtool.exe CLI takes creds as an argument, making it a lot easier.

[rtibbles]

Jose went through the trouble of demoing how to sign debs with me and I never used that training after the first and only time I made a release over a year ago

I know how to create the keys, I just didn't think creating them on my personal laptop was the best course? Assumed it might be better to have the private key and passphrase created in some institutionally secure way and stored in our internal secrets.

Is this for le-downloads/the download page on the site?

Yes, this is for uploading to the le-downloads bucket. I am using a Google Cloud Platform provided action to setup the credentials, so I just need the appropriate credentials for that!