Attach binaries to release

[beadon]

I would like to attach the libraries (and/or packages) to the github release.

Details -
https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository

This would :

1. remove the need for a nightly build system
2. only require building when releases are made
3. reduce traffic load on the build webserver, relying instead on github to serve up the compiled artifacts.
4. take 1 step closer to testing driven with github actions.
5. reduce overhead/maintenance, and perhaps costs(?)

Open to discussion.

[hoehermann]

Hi Bryant

Thank you for the suggestion. I am aware of the github "Releases" section. It is just that building locally and uploading the build artifacts manually bores me and feels tedious.

I feel I need to make something clear about point "2. only require building when releases are made": I wrote it in the past and I will write it again: Updated builds need to be provided whenever whatsmeow is updated. That happens rather frequently. I prefer having a build system over doing it manually.

github access tokens have become quite intricate. Maybe there is a way I can push build artifacts from the build system to the release page automatically.

[beadon]

yes, I hear you on 2 , I think there's an opportunity to build if the downstream dependencies change. It should be right in this mix to trigger the flow:
https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows

...and for attaching things in a non-boring way once that build from the build system is done, then it appears this is the tool to use to stuff the artifacts onto a github release : https://github.com/actions/upload-artifact . I have done nothing more than very basic research here.

This also means a decent set of testing to catch integration problems and flag them, but maybe the workflow trigger is the place to start, then you're only building as-needed ( probably needs a control to prevent building TOO often , -- prevent building more than 4x? per day. )

[hoehermann]

As a follow-up to this discussion, I educated myself on github Actions. Previously, I was under the impression that I had to provide my own runner or pay for the service. Apparently, I was mistaken. Or times have changed. Anyway, building via github actions is free. I managed to create https://github.com/hoehermann/purple-gowhatsapp/blob/ghactions/.github/workflows/build.yml, which produces a win32 build. :)

The build is triggered by pushing to the repository only. No nightly builds happen when whatsmeow changes. Not ideal, but it is a step towards providing releases here on github in an automated fashion.

My eagerness to fiddle around with github Actions is satisfied for now. A workflow building a package for Ubuntu may be created later or by someone else.

Update: While the github runner indeed does produce a binary, it is not actually usable (crashes on load). :| Writing the action was tedious enough with these issues:

• MSYS2 being pre-installed, but not actually in a usable fashion since it is not in PATH
• MinGW is installed, but only the 64 bit version
• go also comes pre-installed, but only the 64 bit version and actions/setup-go will not easily install the latest version in 32 bit since it picks up the installed version to save bandwidth

Apparently, the github-provided windows image is just not made for 32 bit builds. To be fair, I can understand that.

Update: I managed to use MSYS2 for building and the result is actually usable. :)

[beadon]

sweet !

[hoehermann]

While I could not make it work more than once, I am now offering the build straight from the github action runner via https://nightly.link/hoehermann/purple-gowhatsapp/workflows/build/whatsmeow/libwhatsmeow.dll.zip.

[hoehermann]

I am planning to publish a new release soon, but I do not wish to put effort into automating releases with github actions again. @beadon, can you look into it?