Changing label should not trigger CI run

[yungyuc]

Changing labels triggers Github Actions CI runs, but it should not. It is especially annoying when adding comment right before merging.

The desired behavior is:

1. When skip-ci label exists on the PR, subsequent push does not trigger CI run.
2. When skip-ci label does not exist on the PR, subsequent push triggers CI run.

This relates to issue #814.

[rockleona]

@yungyuc is there any reference PR I can check?

However, I tried to leave a comment under PR (reference: rockleona#1) in my repo, but it did not trigger the action.

Another thing I spotted is in profiling.yml, it do not limited the trigger event, but not really relate to this issue I think.

[yungyuc]

@yungyuc is there any reference PR I can check?

However, I tried to leave a comment under PR (reference: rockleona#1) in my repo, but it did not trigger the action.

I don't have a concrete example, so it's possible that I wrongly attributed the reason of CI job rerun to commenting.

Could you please help clarify what triggers CI job rerun under the current setting?

Another thing I spotted is in profiling.yml, it do not limited the trigger event, but not really relate to this issue I think.

Profiling should be run at schedule, so it is the expected behavior to ignore PR.

[rockleona]

I don't have a concrete example, so it's possible that I wrongly attributed the reason of CI job rerun to commenting.

Could you please help clarify what triggers CI job rerun under the current setting?

Each action had different triggers:

Workflow (file)	Triggers
profiling	push, pull_request (any actions), schedule
lint	push, pull_request (types: opened, reopened, synchronize, labeled, unlabeled), schedule
devbuild	push, pull_request (types: opened, reopened, synchronize, labeled, unlabeled), schedule
nouse_install	push, pull_request (types: opened, reopened, synchronize, labeled, unlabeled), schedule
check_skip_ci	workflow_call
send_email_on_fail	workflow_call

Another thing I spotted is in profiling.yml, it do not limited the trigger event, but not really relate to this issue I think.

Profiling should be run at schedule, so it is the expected behavior to ignore PR.

As the table above, should we remove other triggers and keep schedule only?

[rockleona]

From #868, the comment had mentioned a unexpected CI re-run, since @yungyuc had labeled the PR, so it triggered the re-run.

[yungyuc]

Profiling should be run at schedule, so it is the expected behavior to ignore PR.

As the table above, should we remove other triggers and keep schedule only?

You table does not seem to be correct. Right now profiling is only triggered by schedule.

From #868, the comment had mentioned a unexpected CI re-run, since @yungyuc had labeled the PR, so it triggered the re-run.

Good catch. The desired behavior is:

1. When skip-ci label exists on the PR, subsequent push does not trigger CI run.
2. When skip-ci label does not exist on the PR, subsequent push triggers CI run.

Could you please help?

[rockleona]

As the table above, should we remove other triggers and keep schedule only?

You table does not seem to be correct. Right now profiling is only triggered by schedule.

Actually it is correct, in L4, L5 of profiling.yml,the values are empty, that means it will triggered by any branch commit of push (ref) and any action in pull_request (ref, includes all actions mention in this section).

So if we only need to trigger by schedule, I will remove these two keys in this file.

Good catch. The desired behavior is:

1. When skip-ci label exists on the PR, subsequent push does not trigger CI run.
2. When skip-ci label does not exist on the PR, subsequent push triggers CI run.

Could you please help?

I will make a PR later.