search

shurcooL / githubv4

Package githubv4 is a client library for accessing GitHub GraphQL API v4 (https://docs.github.com/en/graphql).
MIT License
1.1k stars 89 forks source link

feat: create automation for schema updates #111

Open wwsean08 opened 1 year ago

wwsean08 commented 1 year ago

This CI job automatically opens a PR when a change happens to the graphql schema to hopefully create a quicker turn around time for updates. I've set it to run nightly or manually (by people who have the necessary permissions) via the github UI. I've done some testing in my fork here where I rolled back the master branch a few commits then cherry picked this change just to verify it works as expected. To be tested is the cron scheduling portion however I don't see that being an issue and will be tested within the next 24 hours once it actually hits 2AM UTC.

If you want to create an automation label or something I can add that, or make any other tweaks, but I think this would be a nice improvement to the repo.

Test Cases:

  1. Initial run, which created this PR
  2. Second run to verify that it wouldn't create a duplicate PR which it didn't per the docs
  3. Third run after closing (not merging) the initial PR to make sure it opened a new PR as documented.
  4. Fourth Run after merging the PR created in the third run to verify that no unexpected PRs are created
  5. Fifth Run scheduled run occurred as expected
  6. And another run down the line opened this PR using a scheduled run, https://github.com/test-organization-wwsean08/githubv4-test/pull/3
dmitshur commented 1 year ago

Thanks for suggesting and implementing this, and sorry I didn't get a chance to comment sooner. I've had the idea of doing something like this for some time and I've seen it successfully used in https://github.com/FiloSottile/intermediates for example. However, at this time I'm not sure if there's a way to benefit from it in this project.

The difficulty in going to full automation here is that even though the "regenerate for schema changes" changes are predominantly no more than the output of go generate, I do try to review the changes and pay some attention to improvement opportunities. For example, a8d4a561cc93301cb06fef837857a8562304a349 added special handling of the SponsorsCountryOrRegionCode enum, 420ad0987b9b0a4febc06dceb9b0ea129ab896c2 for SCIM, and efb623903184656cfeaaf308f6cdc3f74aaa49ee for some brand name spelling.

Given I want to look over the change after the trivial go generate step and sometimes apply additional changes, it seems trying to automate this doesn't buy much compared to just doing it manually. I wanted to explain why I'm not prioritizing this opportunity higher at this time, though I may still want to revisit this at some point.