cd: generate release binaries using GitHub actions

[div72]

No description provided.

[jamescowens]

Very happy to see this...

[RoboticMind]

Note for naming the binaries: for the gridcoin.us site to pull the correct links, it expects/uses that:

• The Windows releases will have win64 somewhere in the filename for 64bit Windows and win32 somewhere in the filename for 32bit Windows
• Chesksum files end with .SHA256 in all caps
• Hotfixes will override the links if hotfix is somewhere in the filename (done independently between 32bit and 64bit windows)

See the fetch-release.js file on the Gridcoin site

Not sure if this draft currently follows those, but just putting that out there just in case

[jamescowens]

We should follow those rules. @div72 ^

[div72]

You can see the release binaries produced at my fork. The files aren't renamed after make deploy so the first point isn't an issue, the second point is neither as the sha256sum output is {file}.SHA256.

The unhandled case is the hotfix one, CD is only ran after tag pushes/releases but hotfixes aren't releases. I can make a separate action to generate hotfix binaries for either pushes to the hotfix branch or a manual trigger. @jamescowens What do you think?

[jamescowens]

Maybe we should do hotfix tags?

[Pythonix]

I will pay a bounty of 1k GRC for @div72 once this PR is merged.

[div72]

I mean I am not complaining but why?

On a semi-related note, I really should get the grcbountybot going.

[Pythonix]

I mean I am not complaining but why?

On a semi-related note, I really should get the grcbountybot going.

I remember back in the day when it always took forever for someone to be able to compile the Windows version. To automate the whole thing is very good!

[RoboticMind]

Other questions: what MacOS version(s) does the DMG file work for? We should put it in the filename probably since they usually only work for a few MacOS versions since Apple breaks things a lot

[cyrossignol]

Happy to see this too. What is the advantage of creating a separate tree for CD? It may be hard to keep the CI and CD code aligned with the duplication. Do we really want this automation to post a formal GitHub release? We'll need to limit the scope of the branches to avoid accidents. Why not have the builds publish artifacts attached to each run instead?

[div72]

@cyrossignol

What is the advantage of creating a separate tree for CD? It may be hard to keep the CI and CD code aligned with the duplication.

CD scripts are simpler than CI scripts as they are only meant to run on GitHub actions, while CI scripts can be run anywhere. There are also a few points where the scripts differ(like the mount of /release in docker, lack of tests, lack of make distdir to correct abs_top_srcdir) so I opted in separate them.

Do we really want this automation to post a formal GitHub release?

The script by itself does not post GitHub releases unless a tag is pushed. When a new release is published on GitHub, a new tag will automatically be generated and the script will just populate the release with binaries.

We'll need to limit the scope of the branches to avoid accidents.

What do you mean?

Why not have the builds publish artifacts attached to each run instead?

The build artifacts are only downloadable when logged in which is something I prefer not to have in releases. Also anyone involved in development should be able to compile on their own so no it's redundant in my opinion.

[jamescowens]

I am satisfied with this. Merging.

[Pythonix]

Very cool! I have already transferred the bounty of 1k: 5b87efe1b5e33cfc26779d91ba4ea6970774e3bcf6b5cd7bfec608f18b9911e1