Comments (11)
@gr2m Do you think it would be reasonable to add support for auto-pagination in this action? We do have the pagination plugin for Octokit, so it doesn't seem like a huge over-reach. We would have to think about whether we should paginate by default.
from request-action.
I think this would be a reasonable thing to add, but I don't think I'm going to have time to add it myself. I'll reopen this issue so the request is tracked.
from request-action.
Yup, looks like a pagination issue. In the debug logs I see this in the headers:
"link":
<https://api.github.com/organizations/<ORG>/packages/container/<CONTAINER>/versions?page=2&per_page=30>; rel="next",
<https://api.github.com/organizations/<ORG>/packages/container/<CONTAINER>/versions?page=2&per_page=30>; rel="last"
from request-action.
So, the question is how to return all results, similarly to the --paginate
argument in the gh
cli?
from request-action.
Ok, changing the UR to the below works:
route: GET /orgs/{org}/packages/container/{container}/versions?per_page=100
...but this will break if you have >100 image versions 🤢
That's just a hack - it doesn't fix the issue, it just pushes the goalposts a bit further out.
If there really is no way to specify to return all results (similar to the CLI) I guess this issue can be turned into a feature request for that functionality.
from request-action.
Sorry pagination is not supported by this action. It's a supper thin wrapper to send requests to GitHub's REST API. I'd suggest to use an alternative action in this case.
from request-action.
Silent truncation of data is a pretty user-hostile default which I think deserves a big warning in the README.
Warning
This action only returns the first page of data, which by default is only the first 30 results.
If you need more than 30 results you can append the?per_page=100
query to your url.
If you need more than 100 results you will need to use another tool to request all of the data.
from request-action.
The action is a tool to utilize GitHub's REST API, the REST API documentation should be clear enough about the pagination limitation.
I do agree however that the description at https://docs.github.com/en/rest/packages#get-all-package-versions-for-a-package-owned-by-an-organization is misleading.
Returns all package versions for a package owned by an organization
Should be reworded to
Lists package versions for a package owned by an organization
That would be coherent with other List ...
endpoints. It would be great if you could file an issue with the docs team
from request-action.
The action is a tool to utilize GitHub's REST API, the REST API documentation should be clear enough about the pagination limitation.
I do agree however that the description at https://docs.github.com/en/rest/packages#get-all-package-versions-for-a-package-owned-by-an-organization is misleading.
Returns all package versions for a package owned by an organization
Should be reworded to
Lists package versions for a package owned by an organization
That would be coherent with other
List ...
endpoints. It would be great if you could file an issue with the docs team
I've created a PR internally at GitHub to fix this. Good spot!
from request-action.
Do you think it would be reasonable to add a support for auto-pagination in this action?
I very much think it will be worthwhile. Even though my use-case isn't mission-critical, I still plan to move to a solution which lets me get all of the data - hopefully I won't need to!
It's all well and good targeting a *"thin wrapper", however the REST API implements a mechanism to get all of your data - just follow the links recursively. gh api
is also a thin wrapper and it has implemented the pagination in a way that makes sense for that tool. Without providing a mechanism to implement pagination in this tool it's only implementing subset of the functionality.
For me, a tool designed to get data which by default will silently truncate your data and provides no mechanism to actually get all of your data doesn't make much sense.
from request-action.
@gr2m Do you think it would be reasonable to add support for auto-pagination in this action
I would prefer we do not add auto-pagination.
There are tons of other features we could implement that is part of Octokit but not of this action. Before going down this path I'd suggest we update the README and link to workarounds if pagination is needed.
- You could create a dedicated action that does the pagination and link to that action
- We could link to https://github.com/actions/github-script
from request-action.
Related Issues (20)
- Node.js 12 warnings HOT 1
- Cannot view repo details
- [DOCS]: handleError example does not handle errors HOT 1
- [BUG]: sensitive output (`actions/runners/registration-token`) can't be masked HOT 3
- [DOCS]: Example of required_status_checks on branch protection ON HOT 1
- [ASK]: What is GITHUB_TOKEN?? HOT 1
- "Resource not accessible by integration" HOT 2
- [BUG]: Deprecation of GitHub Actions save-state and set-output commands
- Request Dependency Updates for dcl-node-runtime and vm HOT 2
- Having this problem "Bad Credentials" HOT 8
- > I see some repositories using `npm run build` HOT 1
- [MAINT]: Update runtime to Node 20 HOT 2
- [FEAT]: Support onprem github api calls HOT 3
- [BUG]: Attempting GET on a Github commit API fails HOT 5
- [FEAT]: Add fail_on_error option to suppress failing HOT 1
- How to call add Tag? HOT 1
- [Question]: How to use this action with `POST /repos/{owner}/{repo}/check-runs` HOT 4
- [DOCS]: Clarify how to set body inputs HOT 3
- [MAINT]: Node.js 16 deprecation warning HOT 2
- [BUG]: Proxy error HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from request-action.