chore: optimize pull-requests workflow
This PR modifies the pull requests GitHub workflow.
Relevant checks will be run conditionally only if the related src files are changed.
It also includes an additional build checks on apps/docs (Closes #756)
Test Plan
Observe that all the workflow steps unrelated to this PR were skipped.
Indeed this PR only modifies a yml files in .github, observe that it doesn't belong to any glob patterns part of the list of files we want to track.
So as expected for this PR:
- test job: all the test job steps are skipped
- style job: all the steps unrelated to this PR (contracts, subgraph building, eslint...) are also skipped
Testing still left to do: I want to test making some fake changes to the different areas (circuits, contracts etc...) to verify testing/style steps aren't skipped when they shouldn't.
Related Issue(s)
#756
Next
Mirror these changes in the production workflow once approach in this PR is agreed on.
Checklist
- [x] My code follows the style guidelines of this project
- [x] I have performed a self-review of my code
- [x] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [x] My changes generate no new warnings
- [x] I have run
yarn formatandyarn lintwithout getting any errors - [ ] I have added tests that prove my fix is effective or that my feature works
- [x] New and existing unit tests pass locally with my changes
- [ ] Any dependent changes have been merged and published in downstream modules
@baumstern
Before I open a PR, I like to make sure everything's checked out by testing different sections—like circuits and contracts—with some dummy changes in my forked repo. Typically, I'll switch the CI trigger from something like pull_request trigger to push trigger and check if the CI runs succeed for different scenarios. Once everything looks good, I go ahead and open the PR.
yes that's more or less what I usually do too. :wink: I also like to open PRs early to get feedbacks early too and avoiding putting to much work into something that may go in the wrong direction.
https://nektosact.com/ this is really nice, I didn't know! Will definitely use it in the future!
I had a few mistakes in the workflow files that I fixed in the last commits. These workflows triggered on branches with fake changes demonstrate the expected behavior (what should be skipped is skipped, what should not be skipped is not):
I'd say another review should be ok to merge.
@baumstern how does it look?
Let's merge this before #757
Thanks @sripwoud for the great work.