feat: add plugin to fetch terasology engine info from github#197
feat: add plugin to fetch terasology engine info from github#197jdrueckert merged 6 commits intomasterfrom
Conversation
jdrueckert
commented
Jan 12, 2023
jdrueckert
commented
- adjust .gitignore
- add workspace
- consume plugin
skaldarnar
left a comment
skaldarnar
left a comment
There was a problem hiding this comment.
We can move forward merging this to unblock you working on the module and engine pages with good first issues listed.
But in the long run, I think we should only have a single custom source plugin and just fetch information for both the engine and modules.
| query Engine { | ||
| organization(login: "MovingBlocks") { | ||
| repository(name: "Terasology") { | ||
| issues(first: 10, filterBy: {labels: "Good First Issue", states: OPEN}, orderBy: {field: UPDATED_AT, direction: DESC}) { |
There was a problem hiding this comment.
Why are we only fetching the first ten issues here? This seems to be quite a few, and even if we fetch more we can still decide to only display a few on the page...
There was a problem hiding this comment.
Let's change this to fetching all of them with respective pagination in a follow-up PR
| nodes { | ||
| id | ||
| title | ||
| author { | ||
| login | ||
| } | ||
| labels(first: 10) { | ||
| nodes { | ||
| name | ||
| } | ||
| } | ||
| updatedAt | ||
| url | ||
| } |
There was a problem hiding this comment.
This is (naturally) the same structure as we use for fetching issues for modules. We could use GraphQL Fragments to make sure they always have the same structure.
Which makes me wonder whether this should actually be a separate plugin, or whether we just merge it with the other one for simplicity (and easier sharing of code and query fragments....)
There was a problem hiding this comment.
let's consider doing that in a follow-up PR 👍
| const lastFetchedKey = "terasology-engine-last-fetched"; | ||
| const dataKey = "terasology-engine-data"; |
There was a problem hiding this comment.
I think the caches are scoped for the plugins individually, so prefixing is not strictly required. This applies to the other plugin as well, so that's rather a note to self here...
There was a problem hiding this comment.
guess if we plan to merge the plugins anyway, we can make use of the prefix for scoping then, so keeping it for now.
|
Kudos, SonarCloud Quality Gate passed!
|
2 participants
