Remove the usage of the GitHub API to avoid rate limiting.#32
Remove the usage of the GitHub API to avoid rate limiting.#32MarcelBochtler wants to merge 3 commits intomainfrom
Conversation
The script already requires `bash` so use `[[` and `||` to improve readability. Signed-off-by: Marcel Bochtler <marcel.bochtler@bosch.com>
Remove the usage of the GitHub API to avoid any rate limiting. The API was only used to retrieve the version of the `latest` version. As this creates an issue in enterprise environments with shared IP addresses and the usage of GHES, replace the API access with downloading OSC from `/releases/latest/download/...`. Unfortunately, this requires us to remove caching of the latest version. Signed-off-by: Marcel Bochtler <marcel.bochtler@bosch.com>
As the OSC download no longer requires any authentication and rate limiting is avoided by not using the GitHub API, remove the `github-token` input parameter to simplify the usage of the action. Signed-off-by: Marcel Bochtler <marcel.bochtler@bosch.com>
I feel that this is a rather big drawback. I'm not sure whether it's acceptable for our users. Instead of this back-and-forth, trying to cover all cases with a single action, I start to wonder whether we should simply create separate actions for github.com and GHES users... |
We're not only talking about
How many variants of the action should we maintain? And we're already failing because we're trying to download the latest version of a 5 MB CLI? I'm sure that we can support all the above-mentioned variants with a single action by sticking to some basic rules. |
To answer your rhetoric question: Of course the minimum number we need to maintain while still having readable GitHub action code.
And who defines those rules? For the example the rule that we must neither rely on |
|
To add another perspective, IMO defaulting to `latest' is the wrong approach anyway, because it involves the risk that the action fails if the used instance is not updated immediately after a new major release of the server was made. A more reasonable default would be to get the actual server version from https://eclipse-apoapsis.github.io/ort-server/api/get-versions and download the matching CLI. Unfortunately, the |
| https://api.github.com/repos/eclipse-apoapsis/ort-server/releases/latest \ | ||
| | sed -n 's/.*"tag_name": *"\([^"]*\)".*/\1/p') | ||
| fi | ||
| LOWERCASE_OS=$(echo $RUNNER_OS | tr '[:upper:]' '[:lower:]') |
There was a problem hiding this comment.
You could also get the latest version from the location response header of the latest release URL, without using the API:
$ curl -sI https://github.com/eclipse-apoapsis/ort-server/releases/latest | grep -i "location"
location: https://github.com/eclipse-apoapsis/ort-server/releases/tag/0.52.0
4 participants
Unfortunately, #13 introduced multiple issues when running the action on GHES or on self-hosted runners.
ghmight not be available on self-hosted runnersgithub.comwhen running on GHES is cumbersome and requires a separategithub.comaccount.1) was already solved by #31, but 2) remains an issue.
Revert to the approach that was used before #13 to download
latestfrom/releases/latest/download/....This has the drawback that we won't know the version of
latestbefore downloading it, and therefore (version based) caching becomes impossible.