Have github action only run on master repo, and not on forks?

[Blakeinstein]

I have an action that will always fail on forks due to the lack of secrets.

When I set the action permissions to Allow local actions only.

My test action on PRs fails.

How would I about setting up required permissions?
So that, my deploy/update actions run on my own repo only and my test workflow works on PRs?

[kingthorin]

If you use the event pull_request_target and actually checkout the PR branch (see below) then your PR workflow should be fine.

    - name: Checkout
      uses: actions/checkout@v2
      with:
        ref: ${{github.event.pull_request.head.ref}}
        repository: ${{github.event.pull_request.head.repo.full_name}}

• https://docs.github.com/en/free-pro-team@latest/actions/reference/events-that-trigger-workflows#pull_request_target
• https://github.blog/2020-08-03-github-actions-improvements-for-fork-and-pull-request-workflows/

Currently there isn’t a way to control enable/disable state of workflows in forks.

[Blakeinstein]

I am checking out the branch… am I supposed to add the refs?

also by pr target… I have

on:
  pull_request:
    branches:
      - master

further more. What setting am I supposed to set?
With local actions only, I get

actions/checkout@v2 and actions/setup-node@v2-beta are not allowed to be used in Upvision/upvision.github.io. Actions in this workflow must be: within a repository owned by Upvision.

[kingthorin]

Local actions means those that are in your repo. (Of which you probably have none.)

Here’s a PR action that does markdown linting on submissions to help you get a model/understanding of how things fit together: https://github.com/OWASP/wstg/blob/fd5674975bf20209c13e6a6195744e6cf35d0152/.github/workflows/md-lint-check.yml

[Blakeinstein]

With said changes. I get

image855×271 13.3 KB

[kingthorin]

Okay, so it’s running, that’s great!

[Blakeinstein]

Unfortunately no. Its just stuck there.

[kingthorin]

Is it a public repo, can you provide a link?

[Blakeinstein]

Its https://github.com/upvision/upvision.github.io

[kingthorin]

The gh-test workflow? (It was last updated 2h ago, but looking at your actions tab hasn’t been triggered in 7h.)

Also your publish action is reporting a syntax issue: https://github.com/Upvision/upvision.github.io/actions/runs/339580524

[Blakeinstein]

Yes I had to run tests locally and force merge, because i was on a schedule. The tests never run and await status to be reported.
I am told this happens when a workflow file is updated, but this never happened to me before when I did update the test workflow, but recently started showing up when I tried to restrict actions in forks, even when actions were not updated.

As for the syntax issue, it has something to do with the env action, as its documentation requires it to be configured that way.

[BrightRan]

@Blakeinstein,

The “Allow local actions only” option in the Organization settings means that the actions (don’t confuse with workflows) only defined in the repositories within current organization can be used in the workflows within current organization. The workflows within current organization can’t use the actions defined outside of current organization.
That’s why you get the message:

actions/checkout@v2 and actions/setup-node@v2-beta are not allowed to be used in Upvision/upvision.github.io. Actions in this workflow must be: within a repository owned by Upvision.

Because the “checkout” action and “setup-node” action are defined within the “actions” organization, not your organization “Upvision”.

If you want to use the actions from other organizations, you can:

• select “Allow all actions”, the actions from anywhere can be used in the workflows within current organization.

• select “Allow select actions”, specify the actions you want to run within current organization. The specified actions can be from anywhere.

About workflows from fork repository, there also are some option you can use in the Organization settings.

To view more details, you can see “Disabling or limiting GitHub Actions for your organization”.

[Blakeinstein]

I dont want the actions defined on the main repository to run on the forks. I do not want to expose secrets either.

[Simran-B]

You’re still confusing actions and workflows. You cannot stop forked repos from causing workflow runs by reducing actions permissions. What you want is to disable Run workflows from fork pull requests, but that isn’t available for regular accounts and it seems to be limited to private repos?

Blakeinstein:

I dont want the actions defined on the main repository to run on the forks.

They don’t run in forked repos by default, but it can be enabled by the owner of that fork. Note that this is different from pull requests being opened against your repo, which may trigger a workflow run on your end.

What you could do is to only run jobs if the feature branch is in your repo (not in a fork):

jobs:
  job_id:
    if: github.event.pull_request.head.repo.full_name == github.repository
    ...

[airtower-luna]

In that case you probably don’t need the pull_request event at all, if you use the push event it’ll apply to all branches in your own repository, too, unless you use a branch filter.

That said, looking at your initial post it sounds like you want to run on PRs, just not the deploy stuff:

Blakeinstein:

So that, my deploy/update actions run on my own repo only and my test workflow works on PRs?

I think the easiest solution is:

1. Create a test workflow that doesn’t use secrets, and have that trigger on pull_request (and maybe push for you local branches).
2. Create a separate workflow with push event and branch filter for whatever branch you want to deploy from, and have it do the deploy/update. You’ll probably want to run the tests in that workflow, too, even if it’s a bit of duplication, to make sure only successfully tested code gets deployed.

[Blakeinstein]

I have a workflow that is triggered on pull requests, and that works as intended. But my main workflow that deploys the webpage, is also being run on forks. Its not an issue as they simply error out because of the lack of secrets. But I’d rather not have the workflows run on forks.

[Simran-B]

Adding conditions as I showed should be a viable solution then. Workflows will still be started on forks, but abort early without causing failed workflow runs.

[s-weigand]

@Simran-B gave the solution you want and need 😉

To make the condition more portable (copy/paste) in an organization or your own account you can just use the repository owner name as a condition to match.

In your case just replace

github.com

Upvision/upvision.github.io/blob/41ac1a284e4b3accc09309d852ca3b477d1f395e/.github/workflows/gh-deploy.yml#L10-L11

jobs:
  publish:

with

jobs:
  publish:
    if: github.repository_owner == 'Upvision'

For the forks not to be bothered with the failing workflow they just need to update to your version.

[Blakeinstein]

That is exactly what I needed! Thanks!

Sorry for the earlier confusion!

[devedse]

[kingthorin]

❓

[devedse]

Sorry I mistyped a comment in the wrong place

[jsoref]

Fwiw, what you're doing isn't really ideal.

Instead of hardcoding "is my owner X", it's friendlier to add a condition that checks for the required secrets. This would allow someone else to provide compatible secrets for testing in their fork.

In the simplest case, it can be something like this:
https://github.com/smallstep/cli/blob/94f3d85d3de96deb01e0dbc1b60596ecda12ac43/.github/workflows/triage.yml#L29-L31

For fancier cases, you can make a step w/ an output, or a job w/ an output and then condition other steps/jobs based on those outputs.

[thbeu]

That does not work with the pull_request event, but only with the pull_request_target event.

[jsoref]

Eh? The example is for the issue event, not pull request target.

[ghogen]

The way our organization uses forks, we never want forks of our repo to be able to run any GitHub actions. It's not a question of secrets and permissions, it's a more fundamental issue in that forks are only for working on content changes and submitting them (via PRs) to the original repo, they are not for managing anything like tracking issues or running actions. I think a setting is still needed to disallow GH actions on forked repos, not just something in the individual actions. I guess that's a feature request, since I don't think there's any such setting now.

[jsoref]

How someone else uses their fork of your repository is not up to you, it's up to them.

If you think that your workflows aren't useful in forks, then your template for workflows should have the code to restrict them to your organization.