CI Permission issues in PRs from forks

[Arlodotexe]

Describe the bug

When someone forks the repo and creates a PR, GitHub Actions doesn't run as expected. Instead, it throws errors at us such as:

• Resource not accessible by integration in the experiment job.
• Error: No test report files were found in the Build-WinUI-2 and Build-WinUI-3 jobs.

Steps to reproduce

1. Fork the repo
2. Create a new branch
3. Make some changes
4. Open a new PR, merging your forked repo branch back into `main` in the original repo.
5. Wait for CI to fail.

Expected behavior

CI should pass if changes are valid

Screenshots

Code Platform

• UWP
• WinAppSDK / WinUI 3
• Web Assembly (WASM)
• Android
• iOS
• MacOS
• Linux / GTK

Windows Build Number

• Windows 10 1809 (Build 17763)
• Windows 10 1903 (Build 18362)
• Windows 10 1909 (Build 18363)
• Windows 10 2004 (Build 19041)
• Windows 10 20H2 (Build 19042)
• Windows 10 21H1 (Build 19043)
• Windows 11 21H2 (Build 22000)
• Other (specify)

Other Windows Build number

No response

App minimum and target SDK version

• Windows 10, version 1809 (Build 17763)
• Windows 10, version 1903 (Build 18362)
• Windows 10, version 1909 (Build 18363)
• Windows 10, version 2004 (Build 19041)
• Other (specify)

Other SDK version

No response

Visual Studio Version

No response

Visual Studio Build Number

No response

Device form factor

No response

Additional context

Potentially helpful resources:

• "Resource not accessible by integration" actions/first-interaction#10
• https://docs.github.com/en/actions/using-jobs/assigning-permissions-to-jobs

Notes to assignees

We should be able to safely fix this by branching main and changing the build.yml there, forking the repo, and making a PR to that new branch. That'll cause it to run our modified build.yml against the forked branch.

Help us help you

Yes, I'd like to be assigned to work on this item.

[michael-hawker]

We need the if condition on line 166 for instance before line 163 as well. For at least one issue.

Labs-Windows/.github/workflows/build.yml

Lines 161 to 167 in ed6bd23

	# Push Packages to our DevOps Artifacts Feed
	- name: Add source
	run: dotnet nuget add source "https://pkgs.dev.azure.com/dotnet/CommunityToolkit/_packaging/CommunityToolkit-Labs/nuget/v3/index.json" --name LabsFeed --username dummy --password ${{ secrets.DEVOPS_PACKAGE_PUSH_TOKEN }}
	- name: Push packages
	if: ${{github.ref == 'refs/heads/main'}}
	run: dotnet nuget push "**/*.nupkg" --api-key dummy --source LabsFeed --skip-duplicate

[Arlodotexe]

According to the docs, the value of github.ref in the context of a pull_request trigger is the branch which is being merged into (the base), rather than the branch which is being merged (the fork).

I've confirmed this in #222, we'll need to use a different environment variable that tell us if the branch being merged is from a fork.

@michael-hawker Any feedback or direction? Since this changes when packages are auto-published.

[Arlodotexe]

This might be one of the fixes we're looking for: dorny/test-reporter#168

[michael-hawker]

@Arlodotexe exactly the github.ref is only refs/heads/main when it's being merged into main. You can see that the step for pushing packages doesn't run on a pull request run from a prior PR build here:

So by adding the if condition to this it won't try and add the source and use the unavailable token.

[Arlodotexe]

Doing this adds another (potential?) problem - any PRs that come from a fork won't be published to nuget as part of build validation. We still need to clearly define where/when we want publishing the nuget package to happen.

[michael-hawker]

Synced offline, clarified how the github.ref works and the if statements needed for when we want to push packages only when merging to main.

If need be, we can look at an alternate test reporter now that we're a public repo: #72

@Sergio0694 FYI, just in case you need to add it to the GitHub org.

[Arlodotexe]

After a lot of digging, it looks like we can do this by using 2 separate jobs: 1 that assumes an insecure context and runs builds, and a second that takes the result of the build and runs in a secure context, allowing us to write tags, make comments, report test results, etc.

https://securitylab.github.com/research/github-actions-preventing-pwn-requests