-
I’m trying to figure out how to prevent a step from running on a PR workflow if the PR is coming from a fork. The workflow has a few steps that should always run, like building a docker image. The last step will read repo secrets to publish the docker image to a private repo, but I don’t want that step to attempt to run if the PR came from a fork. The workflow already prevents the fork-triggered-PR from accessing the secrets, and thus gets a failed step, but it would be great if the PR didn’t get a red X on it, and instead just skipped that step. I tried most of the available GITHUB_ environment variables, and none of them seem to provide a way to detect if the source of the PR is a fork. The docs here state:
But this is not true. These are getting set for workflows running on any PR, whether they came from a fork or not. GITHUB_REPOSITORY also seemed promising, but it ALWAYS displays the base repository, and never the fork repository. Is there any way that I can have a step be skipped if the PR originated from a fork? |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments
-
There are three properties of github context you need to know: 2) github.event.pull_request.base.repo.full_name – the repository where the target branch is located. It is same with github.repository. 3) github.event.pull_request.head.repo.full_name – the repository where the source branch is located. According to the three properties: 2) If the PR is merging from a forked repository, the property github.event.pull_request.head.repo.full_name is different with github.event.pull_request.base.repo.full_name and github.repository. So you can use these three properties to check if the PR is merging from the forked repository. I have a simple example here as reference: https://github.com/ForksForTest/TestClock/blob/master/.github/workflows/Test.yml |
Beta Was this translation helpful? Give feedback.
-
github.event.pull_request.head.repo.full_name is exactly what I needed, thanks! For future reference, are these particular properties documented anywhere? I didn’t see anything that listed them when starting from this page: https://help.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions |
Beta Was this translation helpful? Give feedback.
-
Yeah, in the docs, it does not list all the possible properties from the github context, because according the different trigger events, many of the properties (and sub-properties) are different and not inherent. And also consider the number of these properties is huge. So I think it is impractical to list all possible attributes. The docs only lists some main properties from the github context, and most of these main properties have their corresponding default environment variables automatically set by GitHub. These main properties mostly are the inherent properties in the context, no matter the workflow is triggered by what event. Actually, many times we need to print the whole context information to the logs so that we can search and view the properties we need. |
Beta Was this translation helpful? Give feedback.
@sandoichi ,
There are three properties of github context you need to know:
1) github.repository – the repository where the workflow is currently running.
2) github.event.pull_request.base.repo.full_name – the repository where the target branch is located. It is same with github.repository.
3) github.event.pull_request.head.repo.full_name – the repository where the source branch is located.
According to the three properties:
1) If the PR is merging between branches in the same repository, the value of these three properties are the same.
2) If the PR is merging from a forked repository, the property github.event.pull_request.head.repo.full_name is different with github.event.pull_request.…