Dependabot latest change renders this action unusable for public repos

[ahmadnassri]

https://github.blog/changelog/2021-02-19-github-actions-workflows-triggered-by-dependabot-prs-will-run-with-read-only-permissions/

Starting March 1st, 2021 workflow runs that are triggered by a pull request from Dependabot will be treated as if they were opened from a repository fork. This means they will receive a read-only GITHUB_TOKEN and will not have access to any secrets available in the repository. This will cause any workflows that attempt to write to the repository to fail.

If your workflow needs to have a write token, you can use the pull_request_target event; however, this is not viable for public repositories due to security risks

I have not seen any success with pull_request_target simply because no dependabot PRs has landed on my private repos since I changed to using pull_request_target but will update this issue and the README if I can validate them working...

pull_request_target might be acceptable for private repos... but I don't believe that will be good enough for public ones.

[mercuriete]

I tried the following methods:

1. pull_request_target on private repos and it doesn't work for me
2. on: workflow_run: and it doesn't work for me with the same behavior

I hope someone can double-check proving I did something wrong.

upstream bugs related:
dependabot/dependabot-core#3253
dependabot/dependabot-core#2268

[aaronArinder]

for (1), I'm seeing the same issue; I haven't checked (2) yet, but if I find time later, I'll check it out and respond here

[ahmadnassri]

for method 1: are you using a PAT?

[aaronArinder]

@ahmadnassri: I am, with repo scope (it's a private repo) from a user with push perms to the repo

(also, sweet action! I started trying to integrate it yesterday, which seems like bad timing 😆 )

[akheron]

This article linked from the announcement suggests a 2-step strategy where the first workflow runs unprivileged and exposes the checked PR as a build artifact, and the second one fetches that artifact and merges the referenced PR.

[ahmadnassri]

after further inspection of recent private repo PRs, it seems the "March 1st" date from the Github article is false ...

up-until March 8 things were working fine, only on March 9 did the issues start ... (thanks Github for the misleading info)!

this is why I was confused, becuase I saw the article indicating March 1st, and kept an eye on things for that date and ongoing, and everything seems to work fine ... until the 9th!

[mercuriete]

@akheron the 2-step strategy is what I called on: workflow_run and for me behaves similar... github_token it is fine but secrets are empty or not injected. I hope someone can double-check that approach.

[aaronArinder]

@mercuriete: have sample code for that process?

[mercuriete]

this code tries to comment a PR inconditionally

kairos-wallet/web@1f221af

for me it failed like this (reverse patch):
https://github.com/kairos-wallet/web/runs/2085091889?check_suite_focus=true
when using github_token

and like this when using secrets:
https://github.com/kairos-wallet/web/runs/2085126326?check_suite_focus=true

so given that I couldn't make a comment I stop trying using another action.

Another problem is:

Even if you are successful commenting a PR with the following text "@dependabot merge"
the merge will be triggered with dependabot permissions....
and after that merge... the main branch will be triggered without full permissions failing Continuous Deployment to AWS or another steps you have on main branch.

TLDR; So even if we could make a comment on a PR the action will fail on main branch.

[aaronArinder]

alas, there's no sad emoji to respond with

[ahmadnassri]

the merge will be triggered with dependabot permissions....
and after that merge... the main branch will be triggered without full permissions failing Continuous Deployment to AWS or another steps you have on main branch.

is this a new behaviour?

[ahmadnassri]

note: it's REALLY hard to test further variations on this .. since @dependabot recreate doesn't really mimic an actual brand new pull request ... and dependabot is mostly triggered by a schedule or somebody publishing a change to a public package ...

anybody got thoughts on testing?

[aaronArinder]

I've been closing the PRs and using @dependabot close and then @dependabot reopen, but I'm not sure that actually mimics a brand new PR--it seems to get around the 5-recreate-cap, though

[mercuriete]

I could mimic the behaviour with @dependabot rebase after a new commit on main branch.

@ahmadnassri no, It is not a new behaviour.
Remember two days ago when we thought was random?

It turns out It wasnt
It was a manual trigger on PR followed by a failure on main branch. And I think It can be reproduced just commenting @dependabot merge on a PR. (Because the merge is triggered by dependabot instead of a PAT)

[mercuriete]

note: it's REALLY hard to test further variations on this .. since @dependabot recreate doesn't really mimic an actual brand new pull request ... and dependabot is mostly triggered by a schedule or somebody publishing a change to a public package ...

anybody got thoughts on testing?

If you change your main branch to "main-fake" you can downgrade packages and do whatever you want....
after your testing you can delete "main-fake" and then you can change the main branch to "main"

[ahmadnassri]

If you change your main branch to "main-fake" you can downgrade packages and do whatever you want....

ah, good trick

[ahmadnassri]

PSA: I have to start my main work day, which will keep me occupied and away from further trying to debug and address this issue, I appreciate the community's feedback and if ya'll keep testing / trying things, would apprciate if you log them in this issue, so that I can circle back to it.

[akheron]

Would it be possible to have a scheduled workflow go through all open dependabot PRs and merge the ones that have passed all
checks? It would probably be enough to run it e.g. once a day.

[peterbe]

Would it be possible to have a scheduled workflow go through all open dependabot PRs and merge the ones that have passed all
checks? It would probably be enough to run it e.g. once a day.

I don't see why not. They're run on the origin repo, so you'll have the ability to post comments.
A caveat that I would fear with something like this is that two (Dependabot) PRs might have succeeded individually, and one is not merge conflicting with the other, but when "combined" they'd potentially break CI.
A solution to that would be to write something like this:

# Runs on a 1h cron job

first = true
second = true
for dependabot_pr in all_passing_dependabot_prs_sorted_by_oldest_to_newest:
  if first:
    approve_pr(dependabot_pr)
    post_comment("@dependabot merge", dependabot_pr)
    first = false
    continue
  if second:
    post_comment("@dependabot rebase", dependabot_pr)
    break

That way, it carefully merges one at a time and forces a rebase on the "next one". And repeat.

(sorry if that comes across as obvious but it's still worth pointing out)

[peterbe]

One thing I don't understand is; why would it be dangerous/insecure for public repos?.
You can definitely "tighten" it by checking the PR author and check that it's not a PR coming from a fork, because dependabot makes its PRs on the origin repo.

I appreciate that you don't want to combine npm install (or make build or whatever) in the same context as you have write-access secrets. If you break it up so that there's a workflow_run workflow, then that workflow will not run npm install but only the steps that auto-merge does today (create an approved review request, post a @dependabot merge comment).

This is what @akheron suggested in this comment: #60 (comment) ...if I understood that correctly.

This way you do any npm install in a in-secure context, and the PR comments in a secure context.

Not sure how this relates to the auto-merge action.

[ahmadnassri]

PSA: confirmed that pull_request_target + PAT works fine for private repos. I got a wave of dependabot PRs come in over night and they all worked after switching to pull_request_target yesterday

[ahmadnassri]

a side effect: even though switching to pull_request_target for this action works, since dependabot now makes its PRs are treated as a fork, you might have other workflows that end up failing (e.g. one you trigger on pull_request and do other activities like npm install with a private token)

that workflow no longer works (because of the secrets thing) and will fail, which makes @dependabot merge command not want to merge cuz of the failure...

so now you are faced with the prospect of having to change ALL the other workflows to also run on pull_request_target just so the auto merge works

[peterbe]

since dependabot now makes its PRs from a fork

Uh? I don't see that.
mdn/yari#3212 for example was made by Dependabot. It's on the original repo. Not a fork of the repo.

Either way, I'm going to test simply changing my auto-merge.yml from pull_request: to pull_request_target: and see if it solves things.

[ahmadnassri]

@peterbe: see https://github.blog/changelog/2021-02-19-github-actions-workflows-triggered-by-dependabot-prs-will-run-with-read-only-permissions/

"a pull request from Dependabot will be treated as if they were opened from a repository fork."

whatever internal magic (if statements) are doing in github's side to treat it as a fork /shrug

[ahmadnassri]

@peterbe in your case, all workflows seem like they will work if you switch them to pull_request_target, except for lighthouse / performance workflow since it needs a secret .. (secrets.LHCI_GITHUB_APP_TOKEN) if you switch it, you might risk leaking that secret to any random PRs

[peterbe]

@peterbe: see https://github.blog/changelog/2021-02-19-github-actions-workflows-triggered-by-dependabot-prs-will-run-with-read-only-permissions/

"a pull request from Dependabot will be treated as if they were opened from a repository fork."

whatever internal magic (if statements) are doing in github's side to treat it as a fork /shrug

Sorry. I misinterpreted your sentence. It says they'll be "treated" as if from a fork.

[ffflorian]

If there is a problem with rebasing, we could try using synchronize as target like so:

on:
  pull_request:
    types: [synchronize]

[bennycode]

I tried synchronize in another project of mine:

on:
  pull_request_target:
  pull_request:
    types: [synchronize]

But it looks like it runs in a different context with limited permissions because I am now seeing the following error:

/action/node_modules/@actions/core/lib/core.js:94
throw new Error(Input required and not supplied: ${name});
Error: Input required and not supplied: github-token

Build: https://github.com/bennycode/ig-trading-api/pull/176/checks?check_run_id=2645794063

EDIT: I found the solution to my problem. I forgot to run actions/checkout before ahmadnassri/action-dependabot-auto-merge, so it could not consider the semver version and failed to merge some of my dependencies. I don't need the synchronize target any longer and was able to solve my problem with the following code:

merge-dependencies.yml

name: 'Merge Dependencies'

on: [pull_request_target]

jobs:
  auto-merge:
    runs-on: ubuntu-latest
    # Guarantee that commit comes from Dependabot (don't blindly trust external GitHub Actions)
    if: github.actor == 'dependabot[bot]'
    steps:
      - name: 'Checkout repository'
        uses: actions/checkout@v2.3.4
      - name: 'Automerge dependency updates from Dependabot'
        uses: ahmadnassri/action-dependabot-auto-merge@v2.4.0
        with:
          github-token: ${{ secrets.WEBTEAM_AUTOMERGE_TOKEN }}

[evantahler]

It seems Fastify has a similar Action which solves the permission access problem via a Github App https://github.com/fastify/github-action-merge-dependabot

[steebchen]

Also getting this for unknown reasons in private repositories.

EDIT: ah, seems like pull_request_target works. Would be nice to highlight this in the readme

[james-s-w-clark]

Been struggling with github-token credentials stuff for a while - there's a few open tickets about this.
I am running this in a private repo. I have push permissions. I tried the following:

name: auto-merge

on:
 pull_request_target:

jobs:
 auto-merge:
   runs-on: ubuntu-latest
   steps:
     - uses: actions/checkout@v2
     - uses: ahmadnassri/action-dependabot-auto-merge@v2
       with:
         target: minor
         github-token: ${{ secrets.GITHUB_TOKEN }}

I get this: