chore(workflow): specific target directory in Test process action

[HsiangNianian]

No description provided.

[github-actions]

Package Changes Through 3b6995c

No changes.

Add a change file through the GitHub UI by following this link.

---

Read about change files or the docs at github.com/jbolda/covector

[fu050409]

@HsiangNianian Thanks for you contribution, however, we're using required workflow to ensure we won't merge some pull requests contains issues unexpectedly, which depend on GitHub branch rules. I think we should not do this.

[HsiangNianian]

@HsiangNianian Thanks for you contribution, however, we're using required workflow to ensure we won't merge some pull requests contains issues unexpectedly, which depend on GitHub branch rules. I think we should not do this.

TL;DR I understand what you mean, and I highly recommend this approach, please allow me to explain this PR

In actions, especially push and pull_request events, paths have been added to indicate that the Test workflow will only be triggered when the commit path contains the src or test folders (i.e., both have been modified)

This is done to reduce the unnecessary workflow overhead caused by file changes under other paths

At the same time, in the community, we should strive to promote this type of workflow, workflows are event-based, but you still need to clearly distinguish between the project directories corresponding to different workflows and the different paths and partitions in the project architecture, look at the following e.g.(workflow architecture for documents updates):

name: Build Docs

on:
    push:
        - "docs/"

# ...

You will benefit from this, but dont panic, you can add or remove paths at any time :D

[fu050409]

@HsiangNianian I have to say that I agree with your idea. I add this path check for my personal account too, however, I have to remove branch protect rule for ci checks since PRs without test checks cannot be merged. But there is no workaround to add a GitHub based rule to avoid our maintainers merging PRs that failed on test checks without branch protect rule.

[HsiangNianian]

@HsiangNianian I have to say that I agree with your idea. I add this path check for my personal account too, however, I have to remove branch protect rule for ci checks since PRs without test checks cannot be merged. But there is no workaround to add a GitHub based rule to avoid our maintainers merging PRs that failed on test checks without branch protect rule.

I understand your concerns, but this is a harmless thing. You can try it. I suspect two outcomes:

1. The checks continue but are blocked or skipped. The contributor cannot set up automatic merger.

2. there is no test check(or Pending), PR can be automatically merged after other workflows checked

I would prefer the second scenario, at the same time, you need to understand what workflow audits mean, and you can request a corresponding workflow for changes to files in other paths which are not relevant for development (although it doesn't mean too much)

[fu050409]

@HsiangNianian Here's what actually happens:

1. If we keep GitHub's branch protection policy in place, then if a change in a pr is not within the specified path, the corresponding ci check is not triggered. For example, we have a test check, which means that no member has permission to merge a pr that doesn't trigger this task, since passing the test check is mandatory. Even if it's not triggered, GitHub will assume that the pr didn't pass the expected check and block all merges.

2. If we remove the corresponding mandatory branch protection to allow PRs that don't triger a test check to be merged, then our maintainer might accidentally merge a pr that triggers but fails the test, and GitHub won't block the merge because passing the test isn't mandatory, even if it fails.

In the last change I think it makes sense, this at least reduces the overhead of the main branch. Overall, thanks for your contribution.