Automate release and build distributable binaries

[jm-clius]

Problem

We need to automate the release process for nim-waku, including building and uploading distributable binaries for all the major OSs/architectures.

The nimbus-eth2 release workflow can serve as inspiration.

Acceptance criteria

A GH workflow that creates a

• tagged GH release
• uploads binary distribs as release asset for all major operating systems and architectures

[vpavlin]

Looking at https://github.com/waku-org/nwaku/blob/master/docs/contributors/release-process.md it does not seem like the release/vX.Y.Z branches has been created before - are they only created when needed (i.e. in case of hotfix/ Z-stream release) or is it because the process has not been properly followed?

[vpavlin]

We could add https://github.com/marketplace/actions/semantic-pull-request to our PR workflow to make sure the PR title follows the semantic commit pattern

[vpavlin]

Reviewing https://github.com/status-im/nimbus-eth2/tree/stable/docker to replicate the multi-arch builds for nwaku

[vpavlin]

I've noticed the current released artifact tarball contains the build/ directory:

/home/vpavlin/Downloads/nim-waku-ubuntu-latest/
└── build
    ├── chat2
    ├── networkmonitor
    ├── wakucanary
    ├── wakunode1
    └── wakunode2

Is that necessary? I would probably either remove the subdir or used bin/ instead of build/.

WDYT @jm-clius ?

[jm-clius]

Not necessary, I'd say. I also don't have any strong feelings about whether it should be in a subdirectory at all. The only important thing is to clearly communicate this change in the next release, in case some client teams have built tooling that assume the subdirectory.

[arnetheduck]

One useful nuance of the nimbus release process is the split into unstable/testing/stable - ie unstable is where development happens - when it's getting close to release we merge to testing and users are generally expected to use stable - the last one also serves as the "latest released" branch effectively

[vpavlin]

@arnetheduck Yup, I've read through the nimbus release process, workflows and dist related make targets etc.

I like that split and we will eventually move to similar direction.

For now we have agreed on "simply" releasing master - i.e. doing a soft-freeze of not merging anything with potential to disrupt the master a few days before release and then tagging the master and producing the artefacts.

The main goal now is to automate as much as reasonably possible for the current process and then start adding safety nets like multiple stages/branches pre-release

[fryorcraken]

This looks like a milestone @vpavlin . What is the status?
Could you use the milestone template so we can clearly see what's done, what's remaining and what's the scope?

[vpavlin]

I was considering it, but then we created #1889, so I'd say we can close this one in favour of the new oen?

[jm-clius]

I agree that the new issue probably better captures what we still want to do. Closing this one.