track gitlab release in rbm.conf and add command to post comment on build status

was: "Local build automation for sharing results"

new:

per @boklm (#41516 (comment 3391832))

makefile command like torbrowser-post-to-gitlab-sha256sum-release that would post a comment with the build sha256sums (if the build was succesful, if not maybe a message saying the build failed) to the release prep issue

Maybe we could store the release prep issue number in rbm.conf. Having the release prep issue there could also be useful for other things later, for example if we want to extend the signing scripts to automatically check checkboxes of the corresponding steps when the signing is done. Maybe we could also have a script in tools to link an issue to the release prep, which could take the bug number from there.

I think posting the comment can be done using glab (glab package in debian).

old:

during a conversation between @ma1 and myself we dared to dream of even more helpful scripts, and I mentioned I'd played with more build automation and result reporting into threats via APIs (https://git.openprivacy.ca/cwtch.im/cwtch-ui/pulls/988#issuecomment-20781 and https://git.openprivacy.ca/openprivacy/drone-gogs/src/branch/main/gogs-notify)

this came from a building saying their build wasn't done but they were off to sleep meaning we'd have to wait a lot of a day to find out how it went even if it concluded soon. the proposal is pretty simple:

  • add a new Makefile target start-gpg-agent that just actives gpg so the user is prompted for a password before the build runs incase it is not unlocked
  • update build templates in git lab to recommend make start-gpg-agent && make torbrowser-release && make torbrowser-incrementals-release && make torbrowser-upload-sha256sums-release

as one quick step and then a second step:

  • extend the upload-sha256sums-release step in tbb to accept a gitlab api token from rbm.local.conf (like the vpn project is already requiring in local.properties so gradle can fetch our latest internal CI build of onionmasq's .aar) and post the link and results to the thread which would have to be passed in as an argument to that step (or at least the issue number)

discussion about this step:

if we're putting a commenting api token in rbm.local.conf, do we want to get really ambitious to make some kind of triggerable flag (env var?) so that each of the build steps could also use it to report a build failure? off be default but if like TBB_BUILD_ISSUE is defined, the torbrowser-release and torbrowser-incrementals-release could be extended to also post about a failure

Edited by Dan Ballard