graphql
reduce CO2 usage by running less unneccesary GH actions workflows
because it's good for the earth 🌍 and the patience of contributors 😆
i wish you could use paths-ignore further down, to skip individual tasks
note:
i decided to upgrade actions/setup-node usage as well for similar reasons, it appears to be faster but brings some bugs, so i will finish this up tonight
⚠️ No Changeset found
Latest commit: be92e70037ee7bc263cb39bdd3d56e9804462827
Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.
This PR includes no changesets
When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types
Click here to learn what changesets are, and how to add one.
Click here if you're a maintainer who wants to add a changeset to this PR
![changeset-bot[bot] avatar](https://avatars.githubusercontent.com/in/28616?v=4 "Published by a pub.dev verified publisher"){kind=small}
The latest changes of this PR are not available as canary, since there are no linked changesets for this PR.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
a lower priority fix - how to configure workflows to only re-run when only that workflow file changed? probably by using these same configs
this makes me want to decouple cypress tests into seperate workflows, as they and vscode-graphql (will) have seperate e2e suites that should only need to be run together if graphql-language-service changes which is rare but usually a good thing haha.
for now, we could make it so cypress only runs with graphiql related changes, so it could ignore server/cli/vscode changes for example
another possibility, I wonder if some of these extremely edge-case node and graphql-js version matrix tests could just be run on merge to main? that way, a release breaks if it should, but it would be rare. maybe a few times a year at most we have an issue that would be detected with either matrix throughout the entire monorepo
so you know what's fun? mocking various fetch polyfill libraries across node versions, where TextDecoder may or may not be present and more excitement