[FEA]: Simplify GraphQL in our project automation
- Dominant language
- C++
- Stars
- 2.5k
- Forks
- 486
- Avg merge
- 2d 6h
- Merged PRs (30d)
- 295
Description
### Is this a duplicate?
- [X] I confirmed there appear to be no [duplicate issues](https://github.com/NVIDIA/cccl/issues) for this request and that I agree to the [Code of Conduct](CODE_OF_CONDUCT.md)
### Area
Infrastructure
### Is your feature request related to a problem? Please describe.
The automations are hard to read, partly because graphQL isn't a beautiful query language IMO, and partly because they're inefficient queries.
### Describe the solution you'd like
We can and should use the global node IDs of items and query them directly. In action below:
```
query {
organization(login: "${{ env.ORG }}") {
repository(name: "${{ env.REPO }}") {
issueOrPullRequest(number: ${{ env.PR_NUMBER }}) {
... on PullRequest {
id
projectItems(first: 10) {
edges {
node {
id
project {
id
}
}
}
}
}
}
}
}
}' > project_data.json
```
Can be simplified into:
```
query {
node(id: "${{ env.PR_NODE_ID }}") {
... on PullRequest {
projectItems(first: 10) {
nodes {
id
project {
id
}
}
}
}
}
}' > project_data.json
```
Similarly, we don't need separate steps for an issue or PR to get its project specific ID, we can just modify the above query to include `... on Issue` and query that. The output JSON will be the same regardless and downstream mutations don't care if it's a PR or an issue.
### Describe alternatives you've considered
_No response_
### Additional context
This saves us graphQL api usage, and it's always good to minimize that since we don't want to get rate limited on a busy day.
Contributor guide
Assessment
This issue has not been assessed yet.