Bring back yml necessary change types in label checkers

[carlossanlop]

There are some on pull_request_target types in the label checking yml files that I removed but they are actually necessary, so the labeler keeps working after for example: pushing new commits, pressing the update the branch, closing and opening the PR.

Will backport too.

[Copilot]

Pull Request Overview

This PR restores additional pull_request_target event types in label checking workflows to ensure that label checks run on a wider set of PR events (opened, edited, reopened, synchronize, in addition to labeled and unlabeled).

• Extended event types in both workflows
• Ensured consistency across different branches for label-related triggers

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
.github/workflows/check-service-labels.yml	Added extra pull request event types to trigger label checks on release branches
.github/workflows/check-no-merge-label.yml	Updated event types to include additional PR actions for better label check coverage on main and release branches

Comments suppressed due to low confidence (2)

.github/workflows/check-service-labels.yml:8

• Ensure that the added event types like 'edited', 'reopened', and 'synchronize' are properly handled by the label checking logic to prevent unexpected workflow runs.

types: [opened, edited, reopened, labeled, unlabeled, synchronize]

.github/workflows/check-no-merge-label.yml:8

• Verify that triggering the workflow on these additional events does not lead to duplicate or conflicting executions, especially with the 'main' branch configuration.

types: [opened, edited, reopened, labeled, unlabeled, synchronize]

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

[carlossanlop]

@dotnet/dotnet-diag do we need the diagnostics CI leg running in PRs with just workflow yaml changes? I noticed it ran here but not in my backports: #114166 #114167 so maybe it's a setting we can configure to prevent such runs.

[steveisok]

@dotnet/dotnet-diag do we need the diagnostics CI leg running in PRs with just workflow yaml changes? I noticed it ran here but not in my backports: #114166 #114167 so maybe it's a setting we can configure to prevent such runs.

It shouldn't run unless manually triggered. Not sure why since the pipline trigger is none.

runtime/eng/pipelines/runtime-diagnostics.yml

Line 1 in e2424d0

trigger: none

[mdh1418]

@dotnet/dotnet-diag do we need the diagnostics CI leg running in PRs with just workflow yaml changes? I noticed it ran here but not in my backports: #114166 #114167 so maybe it's a setting we can configure to prevent such runs.

It shouldn't run unless manually triggered. Not sure why since the pipline trigger is none.

runtime/eng/pipelines/runtime-diagnostics.yml

Line 1 in e2424d0

trigger: none

Could Component Governance have forced the pipeline to run? Looking at the job preparation parameters, it's the only one that had steps. Would that override the trigger: none?

[steveisok]

Could Component Governance have forced the pipeline to run? Looking at the job preparation parameters, it's the only one that had steps. Would that override the trigger: none?

It doesn't appear to me to be all that structurally different than the codeql pipeline and it does not run on PR's.

https://github.com/dotnet/runtime/blob/main/eng/pipelines/runtime-codeql.yml