Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[9.0] Backport labeling workflow changes #112240

Merged
merged 4 commits into from
Feb 11, 2025
Merged
Show file tree
Hide file tree
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .github/CODEOWNERS
Original file line number Diff line number Diff line change
Expand Up @@ -113,3 +113,4 @@
/docs/area-owners.* @jeffhandley
/docs/issue*.md @jeffhandley
/.github/policies/ @jeffhandley @mkArtakMSFT
/.github/workflows/ @jeffhandley @dotnet/runtime-infrastructure
22 changes: 22 additions & 0 deletions .github/workflows/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
# Workflows

General guidance:

Please make sure to include the @dotnet/runtime-infrastructure group as a reviewer of your PRs.

For workflows that are triggered by pull requests, refer to GitHub's documentation for the `pull_request` and `pull_request_target` events. The `pull_request_target` event is the more common use case in this repository as it runs the workflow in the context of the target branch instead of in the context of the pull request's fork or branch. However, workflows that need to consume the contents of the pull request need to use the `pull_request` event. There are security considerations with each of the events though.

Most workflows are intended to run only in the `dotnet/runtime` repository and not in forks. To force workflow jobs to be skipped in forks, each job should apply an `if` statement that checks the repository name or owner. Either approach works, but checking only the repository owner allows the workflow to run in copies or forks withing the dotnet org.

```yaml
jobs:
job-1:
# Do not run this job in forks
if: github.repository == 'dotnet/runtime'

job-2:
# Do not run this job in forks outside the dotnet org
if: github.repository_owner == 'dotnet'
```

Refer to GitHub's [Workflows in forked repositories](https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#workflows-in-forked-repositories) and [pull_request_target](https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#pull_request_target) documentation for more information.
6 changes: 3 additions & 3 deletions .github/workflows/check-no-merge-label.yml
Original file line number Diff line number Diff line change
Expand Up @@ -4,14 +4,14 @@ permissions:
pull-requests: read

on:
pull_request:
types: [opened, edited, reopened, labeled, unlabeled, synchronize]
pull_request_target:
types: [opened, reopened, labeled, unlabeled]
branches:
- 'main'
- 'release/**'

jobs:
check-labels:
if: github.repository == 'dotnet/runtime'
runs-on: ubuntu-latest
steps:
- name: Check 'NO-MERGE' label
Expand Down
5 changes: 3 additions & 2 deletions .github/workflows/check-service-labels.yml
Original file line number Diff line number Diff line change
Expand Up @@ -4,13 +4,14 @@ permissions:
pull-requests: read

on:
pull_request:
types: [opened, edited, reopened, labeled, unlabeled, synchronize]
pull_request_target:
types: [labeled, unlabeled]
carlossanlop marked this conversation as resolved.
Show resolved Hide resolved
branches:
- 'release/**'

jobs:
check-labels:
if: github.repository == 'dotnet/runtime'
runs-on: ubuntu-latest
steps:
- name: Check 'Servicing-approved' label
Expand Down