You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be nicer if enumeration of the HASH and TAG association was published at the PDK publication point that does not have access control and strict rate limit controls around it, instead of using a github service API to inspect active tags on a live repository.
Proposal
One way to provide this would be in the publish action of the appropriate project containing the PDK contents, download the JSON format once in the action, validate the current and expected tag is present in the file (maybe using jq) and then publish it as a GH deployment.
This way it is not a GH managed API that introspects in real-time the current status of a git repo, therefore has stricter access-
control and rate-limit controls with it (due to potential server side CPU time to answer API request).
It becomes a static content index item that is available alongside the PDK archive (which are also static content) that is a much less strict rate-limit control. It also comes highly cachable/easier for GH to manage API queries, that only needs to change when the PDK catalog is updated.
Maybe a wget or curl of the API data in the action during a PDK publish get it most of the way there.
Publish catalog.json and refresh file everytime PDK content is published.
Modify volare to try to download catalog.json file first, but it can silently fail.
Consider, if this succeeds and $GITHUB_TOKEN is not empty, inform user with soft-error message, this operation no longer requires GITHUB_TOKEN (maybe this item is deferred until some months of successful operation after introduction)
Fallback to current method requiring GITHUB_TOKEN, if this mechanism is left in long term then maybe it should provide a helpful soft-warning the ENV is not setup or blank and a link to documentation section on what to do
The text was updated successfully, but these errors were encountered:
Description
It would be nicer if enumeration of the HASH and TAG association was published at the PDK publication point that does not have access control and strict rate limit controls around it, instead of using a github service API to inspect active tags on a live repository.
Proposal
One way to provide this would be in the publish action of the appropriate project containing the PDK contents, download the JSON format once in the action, validate the current and expected tag is present in the file (maybe using
jq
) and then publish it as a GH deployment.This way it is not a GH managed API that introspects in real-time the current status of a git repo, therefore has stricter access-
control and rate-limit controls with it (due to potential server side CPU time to answer API request).
It becomes a static content index item that is available alongside the PDK archive (which are also static content) that is a much less strict rate-limit control. It also comes highly cachable/easier for GH to manage API queries, that only needs to change when the PDK catalog is updated.
Maybe a
wget
orcurl
of the API data in the action during a PDK publish get it most of the way there.The text was updated successfully, but these errors were encountered: