chore: optimize pull-requests workflow

[sripwoud]

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

Verify only relevant jobs steps are run when corresponding files are changed (steps aren't skipped when they shouldn't): :heavy_check_mark: see https://github.com/semaphore-protocol/semaphore/pull/765#issuecomment-2097836509

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 format and yarn lint without 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

[sripwoud]

@baumstern

[sripwoud]

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!

[sripwoud]

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):

• trigger-contracts
• trigger-circuits
• trigger-libs
• trigger-subgraph
• trigger-docs
• trigger-lint
• trigger-format

[sripwoud]

I'd say another review should be ok to merge.

@baumstern how does it look?

[sripwoud]

Let's merge this before #757

[vplasencia]

Thanks @sripwoud for the great work.