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.

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.

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

With said changes. I get

image855×271 13.3 KB

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

Unfortunately no. Its just stuck there.

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

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

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

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.

@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”.

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

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?

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
    ...

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:

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.

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.

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.

That is exactly what I needed! Thanks!

Sorry for the earlier confusion!