Automatically upload binaries when tagged

[hamishcoleman]

This new workflow job will activate when the repository has a tag added to it. It will upload the binary artifacts generated during the workflows as Assets on a github release page.

This creates a more stable and relatively simpler location to direct people at who wish to download binaries. The most recent (non "prerelease") can be found at a single stable URL: https://github.com/ntop/n2n/releases/latest

Any release automatically created by this job will be marked as "prerelease", allowing a human to check anything needed before github starts showing the new release as "latest". The Assets attached to the release can also be deleted, replaced or added to manually if desired.

(I believe this is also providing the desired result for the first half of #851 but is not directly helpful to people requesting beta-test binaries like in #786 until we start tagging minor and patchlevel releases)

[codecov-commenter]

Codecov Report

Merging #871 (2bf9a20) into dev (7bace37) will increase coverage by 0.05%. The diff coverage is n/a.

@@            Coverage Diff             @@
##              dev     #871      +/-   ##
==========================================
+ Coverage   18.31%   18.36%   +0.05%     
==========================================
  Files          41       41              
  Lines        8547     8565      +18     
==========================================
+ Hits         1565     1573       +8     
- Misses       6982     6992      +10     

Impacted Files	Coverage Δ
src/edge.c	0.00% <0.00%> (ø)
src/sn_utils.c	0.00% <0.00%> (ø)
src/supernode.c	0.00% <0.00%> (ø)
src/sn_management.c	0.00% <0.00%> (ø)
src/edge_management.c	0.00% <0.00%> (ø)
src/edge_utils.c	1.41% <0.00%> (+0.27%)	:arrow_up:
src/pearson.c	66.66% <0.00%> (+3.44%)	:arrow_up:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 7bace37...2bf9a20. Read the comment docs.

[Logan007]

So, preparing a (pre-)release would be as easy as tagging it?

And, pre-releases can be published anytime? Do newer pre-releases overwrite the older pre-releases so we do not have more than one pre-release in the history at a time (same tag re-used)? Like... pre-release 2.9 (always the latest)... 2.8 stable ... 2.6 stable ...?

[hamishcoleman]

Yes, preparing the release is as easy as tagging it :-) - additionally, if you use an 'annotated tag' (with the -a option), the message attached to the tag is used by github as the (initial) body of the release.

If a tag name is re-used (not normally done) then I believe (based on other github automation - not on any testing) that the softprops/action-gh-release action will find the existing release object and append the new binaries to the old object. So, with some manual removal, it could be used.

However, I've usually just created a new tag for each stable release (so, 2.8.3, followed by 2.8.4, etc) and just gone in and deleted the old release when it is discovered to be broken.

The URL used by the github release is calculated directly from the tag name, so they are both easy to work out and stable for the life of a given tag.

[hamishcoleman]

oh, additionally, this ties in with reworking the version number strings used in the code and packaging - if the version number is generated from the git tags then the binaries created by the autobuild are all directly traceable back to exact git commit (which helps when you start publishing numerous alpha/beta binaries)

[Logan007]

I see, we could publish intermediate pre-releases with minor version number (only on odd versions) at some seemingly stable dev level, right?

As for the version number, I understood that, if it were deduced from the tag version number, it still would contain the exact commit, wouldn't it? But that presumably is another whole PR's story...

[hamishcoleman]

I think you have that right, yes - for consistency, I would suggest making the stable tags also always use three components (even if the third is just a dot and zero)

And the version number deducing is indeed another PR's story - however, as a preview, I tagged my dev tree with a "2.9" tag at the point where the tree was updated to 2.9 and when I run git describe on the current head of the dev branch, I get the string 2.9-499-g7bace3755c2d - showing the most recent tag, the number of commits since that tag and an abbreviated commitish to confirm the correct commit has been found

[Logan007]

Okay, I got it. Thank you for additional explanation. Great work!

As for the trifold stable release's version number (in tag), that would still need to be discussed :wink:

[hamishcoleman]

I just had another thought - each release has a descriptive text title, which defaults to the tag name, but can be edited manually to be anything - so if you just want to clearly direct people by their names, that description can be changed to be "2.8 stable" or similar