We might be able to squeeze a lot more performance from our api calls in PR commits collection
Sonnet 4.6 has identified that we are constructing one graphql call per pull request:
https://github.com/chaoss/CollectOSS/blob/96adf3a4d68725db21622673ee6613693c0f5ace/collectoss/tasks/github/pull_requests/commits_model/core.py#L49-L56
Some of these may return very few commits
Other places in the code already batch multiple queries into one graphQL call:
https://github.com/chaoss/CollectOSS/blob/96adf3a4d68725db21622673ee6613693c0f5ace/collectoss/tasks/frontend.py#L207-L212
We should do the same in pull request commits to help make things faster (less waiting for network calls)
(note: this issue should not be confused with the similar issue #420, which describes the same thing for a different part of secondary collection)
We might be able to squeeze a lot more performance from our api calls in PR commits collection
Sonnet 4.6 has identified that we are constructing one graphql call per pull request:
https://github.com/chaoss/CollectOSS/blob/96adf3a4d68725db21622673ee6613693c0f5ace/collectoss/tasks/github/pull_requests/commits_model/core.py#L49-L56
Some of these may return very few commits
Other places in the code already batch multiple queries into one graphQL call:
https://github.com/chaoss/CollectOSS/blob/96adf3a4d68725db21622673ee6613693c0f5ace/collectoss/tasks/frontend.py#L207-L212
We should do the same in pull request commits to help make things faster (less waiting for network calls)
(note: this issue should not be confused with the similar issue #420, which describes the same thing for a different part of secondary collection)