Feat: Skip Performance CI tests for docs and workflows files - #79933
Feat: Skip Performance CI tests for docs and workflows files#79933im3dabasia wants to merge 2 commits into
Conversation
im3dabasia
added
[Type] Automated Testing
| pull_request: | ||
| paths-ignore: | ||
| - 'docs/**' | ||
| - '.github/workflows/*.yml' |
There was a problem hiding this comment.
Added this line to verify that the Performance Tests are skipped.
I'll explore skipping the tests for all other .yml files, except performance.yml.
I think we can skip these tests for Storybook-related changes as well.
There was a problem hiding this comment.
The test isn't marked as Skipped; it's marked as Expected by the CI. This might have something to do with the branch protection rules. What do you think, @Mamaduka?
|
Yes, the performance checks are currently required by CI. Perf checks are nice for generating data and keeping an eye on regressions, but they don't have to be required for PRs. If something breaks, it should be caught by other required checks. Worth sharing in |
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
@Mamaduka, is there any chance we can proceed with this PR? |
2 participants
What?
Part of: #44679
Skip the Performance Tests workflow for PRs that only change docs, workflow YAML files, or Storybook-related files.
Why?
These changes do not affect editor performance, so running the performance workflow for them adds unnecessary CI time.
How?
Adds
pull_request.paths-ignorerules in performance.yml for docs, workflow files, and Storybook-only paths.Testing Instructions
This PR includes a YAML-related file change, and the performance tests did not run. Therefore, I believe this is a reasonable way to validate that the PR works as expected.