google / github-release-retry Goto Github PK

It would useful to be able to point to a directory (as opposed to one or more files) to upload its content recursively.
And thanks ++ for this tool!
We are using github-release-retry in scancode release handling to maintain a our own "PyPI" like repo of pre-built wheels at https://github.com/nexB/thirdparty-packages/releases/tag/pypi
@Abhishek-Dev09 worked out a simple wrapper to walk a directory at https://github.com/nexB/scancode-toolkit/blob/develop/etc/scripts/github_release.py#L72 but it would much simpler to have this baked in upstream here.
Do you want a PR?

To ensure that all the files in a release are correct, I would like to have a checksum check mode.
This would work from a file or directory, then all files would be hashed locally (say a sha256) and then each released file would be downloaded and its checksum computed and verified against the local file.

It seems that GitHub recently introduced a new format for their node ids. Specifically, release asset node ids used to just be a base64 encoded string. Newer node ids look like this: "RA_[base64 encoded bytes]". It looks like the asset id is still encoded within the node id, but the format is different.

We use the ability to extract the REST v3 API "id" from the GraphQL v4 API "node id", even though this is undocumented.

When I upload a large number of files as release assets, I sometimes want to reupload later when I have only a few new files added to a whole directory.
In this case each file is processed one by one.
I feel it may be possible to do something to optimize the case where there are many files uploaded at once.

1. fetch all existing assets data at once
2. compare this with the list of files to upload
3. selectively work on things that need to be added/modified but do not do any further API call for each file

This is likely to speed things up as there would be one bigger API call at the start and then fewer API work after that.