I came upon your solution for enabling sonarqube reporting for pull requests from forks that do not have access to the SONAR_TOKEN secret of the main repo.
However, trying to implement this for our repository, I noticed it doesn't work properly for PRs from forks. It does work for branch builds and PR builds from the main repository.
The reason is that for PRs from forks, at least now, the github.event.workflow_run.pull_requests is empty when the workflow was triggered from a fork PR.
Hi,
I came upon your solution for enabling sonarqube reporting for pull requests from forks that do not have access to the
SONAR_TOKEN
secret of the main repo.However, trying to implement this for our repository, I noticed it doesn't work properly for PRs from forks. It does work for branch builds and PR builds from the main repository.
The reason is that for PRs from forks, at least now, the
github.event.workflow_run.pull_requests
is empty when the workflow was triggered from a fork PR.You can see this in your logs here: https://github.com/medplum/medplum/actions/runs/9843264904/job/27174086298#step:6:3
this is from a fork PR branch, but the corresponding variables are empty, leading to sonarqube thinking this was a check of the main branch.
I found the solution was to store the relevant information in the artifacts as env variables: https://github.com/cta-observatory/ctapipe/blob/3dafbc2468b8dc33705abf489af2a59bc0dc73e6/.github/workflows/ci.yml#L148-L171
and use that in the sonarqube step instead of the event payload: https://github.com/cta-observatory/ctapipe/blob/3dafbc2468b8dc33705abf489af2a59bc0dc73e6/.github/workflows/sonar.yml#L55-L71
You might want to apply the same changes here.