Script to create release on GitHub

[raffienficiaud]

• list existing releases
• creates a release if release does not exist already
• get the release ID
• upload files to the release assets
• replace existing files if needed
• handles pagination
• copyright

This is the first step and this is a python3 script I just wrote. In order to integrate in the other release scripts:

• either I need to port things to make them python3 ready and integrate
• either I just need to call this script, assuming that python3 is available

Let me know what you think. I tested the script like this:

python3 ci_boost_github_upload.py \
    --github-token=my_token \
    --release-tag=rtest7 \
    --github-organization=raffienficiaud \
    --github-repository=release-tools \
    --files '/Users/raffi/Downloads/ACriminisi_DecisionForestsTutorial.pptx' \
         '/Users/raffi/Downloads/MeshLab2016.12.dmg' \
         '/Users/raffi/Downloads/source-archive.zip' \

and it works also with big files: you can see rtest7 here.

It is also possible to pass

• an extra param --replace-existing
• an extra param --description when the release is first created

It is also possible to update an existing release with new files.

This is pure/vanilla python3 and does not require any additional package.

[raffienficiaud]

Concerning the token, I used this, I am not sure if we can restrict more.

[Flamefire]

Have you considered alternatives? E.g. there is https://github.com/j0057/github-release with similar features or without tools: Github actions which does a good job too and is easy to use

[raffienficiaud]

@Flamefire yes I did. I already took a look at the code of the package you pointed me (and it looked quite complicated).

I was initially thinking of adding this script to the file pointed by @grafikrobot (directly from the existing python script), which would be difficult if we use an external package.

Also this is pure python3 without any external requirement: no external package, no pip step to be able to use it.

[raffienficiaud]

@glenfe kind reminder, I am more than happy to discuss.

[sdarwin]

How about gh? The advantage is that it's maintained by GitHub, and is "GitHub’s official command line tool".

This is pure/vanilla python3 and does not require any additional package.

The fact this is a small python3 file is appealing. Still, the gh package could be included in a docker image where there are already multiple dependencies. Adding one more package to a long list doesn't affect much.

@grafikrobot asked about releases:

But only as actual tagged releases?

Tags are meant to be stable. However it's not impossible to modify them.

# create a release:
gh release create develop-snapshot -t "Latest develop snapshot" -n "notes"
gh release upload develop-snapshot /tmp/boost_1_76_0-snapshot.tar.gz
# update an existing release, in place:
git tag -f develop-snapshot
git push -f origin develop-snapshot
gh release upload develop-snapshot /tmp/boost_1_76_0-snapshot.tar.gz --clobber
gh release upload develop-snapshot /tmp/boost_1_77_0-snapshot.tar.gz

[Flamefire]

Tags are meant to be stable. However it's not impossible to modify them.

FWIW: You should never do this. This causes all sorts of problems down the chain (e.g. for package maintainers) You tag and once you publish that's it. An exception could be made if you notice the mistake within minutes of publishing

[sdarwin]

You should never do this.

@Flamefire , yes, for versioned releases, betas, etc. For almost all standard types, even very small point releases, you shouldn't change the tag. But what about frequent ever-changing snapshots such as https://dl.bintray.com/boostorg/develop/ Do you really need to keep track of 100's of unversioned snapshots?

[Flamefire]

I simply would not use tags for that. But yes, that might be an exception. Anyway digressing here.

I do see the value in having this as a Python script. If GH would provide a python package, then I'd suggest using that, but adding a binary or compile step is way less appealing. So I'm fine with the current state

[sdarwin]

I simply would not use tags for that.

Right. But I think github releases are linked to tags, so in order to leverage github to host binary downloads, some tag or another has to be assigned. Or, let the tag go stale. Only refresh the attachment.

[sdarwin]

Thank you for this pull request. Repeating from an earlier comment, the gh cli has a big advantage that it's maintained by GitHub, and is "GitHub’s official command line tool". It supports creating releases and uploading release files in an easy standardized way, and removes the need to maintain custom code which interacts at a lower level with the api. In the current timeframe, using gh seems like the right choice.