some github experiments - just for discussion

[envolution]

I made some changes for a personal workflow that I figured would be worth sharing for discussion.

Key ideas - if an API token hasn't been found by traditional methods, also check GITHUB_TOKEN environment variable which happens to match github actions scripts

based on the included github_testfile.toml

 testssl.sh-git: updated to v3.0.9+r4640+g65c463fcb url=https://github.com/drwetter/testssl.sh/releases/tag/v3.0.9

their project has a latest release which is one release older than the newest release - which in this case is just a maintenance patch for an older version. - this is the idea behind the new flag use_newest_release

use_commit_number=true
use_commit_hash=true

+r4640+g65c463fcb
since we use graphql for any call, it only costs us 1 api usage to collect the version, total number of commits (4640) and the last commit hash (65c463fcb - i shorten for legibility)

I've shared the graphql query that the changes use with sample output to get an idea of some of the bits of info that i found relevant to my needs.

and finally the example variables file just shows how to call them pythonically

If there is interest in some of these ideas, I'd be happy to try help integrate, but for now these work for my personal needs.

[lilydjwg]

I don't quite like to use environment variables because they easily leak into unintended processes. Also GitHub Actions doesn't create such an environment variable---it's explicitly created in the workflow file. One could create a keyfile for nvchecker in a similar way.

To fetch 100 releases, we may quickly run out of quota (a user token has 5000 nodes per hour, and Actions one has only 1000 nodes). We may instead fetch the first tag and use it to create a git describe-like string.

[envolution]

based on my testing it only cost 1/5000 API usage on the user token regardless of the fetch number - but I do agree it's probably too large for the purpose. There didn't seem to be a way for GraphQL to filter specific release types - so I pushed that to the python script instead. The three types I can think of are Latest/Pre-Release/ and the unlabeled release. Maybe a number like 10 is sufficient - I guess it could technically be a configure option too.

[lilydjwg]

based on my testing it only cost 1/5000 API usage

Maybe I misread the doc.

Having an option is more flexible, but also makes the code more complex (and it will stick there for quite a long time for compatibility reasons).

[envolution]

I've done a bit of cleaning and fixed a few bugs I had. I removed the environment token option as well as renamed it to -graphql as i'm not very creative. I've had this working on about 80 random repos for some time now and haven't come across any issues (so i think it's reasonably well tested)

The value of github.py's no token api calls is a a good reason to not replace it, but considering the prevalence of github repos, I'll leave this here in case anyone wants it - with a user token you can query 5k packages/24h and you get quite a lot more package information to play with.