Dependabot unable to open PR's "fatal: could not read Username for 'https://github.com': No such device or address"

[Cameronsplaze]

Subject of the issue

When Dependabot tries to open a PR with this action, it hits a permission issue. When I try, it works fine. Is there a way to let bots open PR's?

Error

You can find the action here.

If this issue is describing a possible bug please provide (or link to) your GitHub Actions workflow.
https://github.com/asfadmin/Discovery-WKTUtils/blob/4a5058c8b1196de4e421543e6c29c61d3a0af723/.github/workflows/auto-merge-prod.yml#L37-L49

Background: The goal of this action, is to move a PR from dependabot, from devel to test, then to prod if test passes. (Don't care if devel passes or not).

[peter-evans]

Hi @Cameronsplaze

Due to this recent change, workflows triggered by dependabot PRs now execute with read-only permission. What that means is that the workflow has no access to your secrets and your secrets.BOT_TOKEN becomes an empty string. Additionally, the default GITHUB_TOKEN is read-only and cannot create resources such as issues or PRs.
https://github.blog/changelog/2021-02-19-github-actions-workflows-triggered-by-dependabot-prs-will-run-with-read-only-permissions/

The reason it works on retry is that the execution has been triggered by a user that has write access to the repository, so the secret can be read during the workflow.

One possible workaround is to trigger the workflow periodically with on: schedule instead of being triggered by the pull_request or push events. This will allow you to read secrets and create a PR using this action.

Alternatively, as described in GitHub's blog post, another way to work around this is to use the pull_request_target event. However, there are risks involved so before attempting this method please read Keeping your GitHub Actions and workflows secure: Preventing pwn requests.

I'm going to pin this issue to help other users find it, because it's becoming a common problem.

[Cameronsplaze]

I completely forgot to reply, I'm sorry!

This did get me past my problem, thank you for that! Normally I'd close this, but I'm guessing with the pin, you'd like to keep it open for a while?

[peter-evans]

No problem. Glad to hear you solved it.

I think we can close this issue and leave it pinned. There is nothing I can do so hopefully pinning it will help people find the information about possible workarounds, which I commented above.

[Cameronsplaze]

Hi @peter-evans!

I'm having the same problem again, but on a private repo. It's the same error, but I'm using a schedule, and it doesn't work to re-run the workflow this time. Dependabot isn't involved in the action at all either.

Just in case it helps, this action is just supposed to check for updates on Docker images, that your own are based off of. (ubuntu, alpine, etc.), and open a PR when the base image hash changes, storing it in a file in the repo.

name: Update with Base Image

on:
  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:
  # Check each day at midnight:
  schedule:
    - cron: '0 0 * * *'

jobs:
  update-base:
    runs-on: ubuntu-latest
    steps:
      - name: Grab the code
        uses: actions/checkout@v2

      - name: Check if Update Needed
        id: check-update
        run: |
          ## If file doesn't exist, quit out with error:
          [ -f "$GITHUB_WORKSPACE/$hash_file" ] || { echo "ERROR: $GITHUB_WORKSPACE/$hash_file not found."; exit -1; }

          ## Get the running and latest versions:
          IMAGE=`cat $docker_file | grep FROM | awk '{print $2}'`
          docker pull $IMAGE
          LATEST=`docker inspect --format "{{.Id}}" $IMAGE`
          RUNNING=`cat "$GITHUB_WORKSPACE/$hash_file"`

          ## If they're the same, CONGRATS, you're done
          if [ $LATEST == $RUNNING ]; then
            echo '::set-output name=NEEDS_UPDATE::false'
          else
            echo '::set-output name=NEEDS_UPDATE::true'
            # Save the new hash
            echo $LATEST > "$GITHUB_WORKSPACE/$hash_file"
          fi
        env:
          hash_file: base_alpine_hash.txt
          docker_file: Dockerfile

      - name: Open PR to update image
        if: steps.check-update.outputs.NEEDS_UPDATE == 'true'
        uses: peter-evans/create-pull-request@v3
        with:
          token: secrets.PERSONAL_TOKEN
          labels: dependencies,docker
          title: "New base version detected: Updating to latest"
          commit-message: Updating docker image hash to newest version

It looks like the same error as before, so maybe they switched scheduled triggers to be read-only as well? And the only work around now is the "pull_request_target" approach you mentioned?

I know I can just have the pipeline rebuild/push the container every night, and skip checking if it needs to all together, but I'd like to have an accurate "days since last update" stamp on Docker Hub if possible.

Any idea what might be going on here? I was thinking it's related to opening a PR to the same branch I'm on this time, but it looks like your action covers that automatically, so I'm confused.

[peter-evans]

@Cameronsplaze I think it's just missing brackets where you are setting the secret.

      - name: Open PR to update image
        if: steps.check-update.outputs.NEEDS_UPDATE == 'true'
        uses: peter-evans/create-pull-request@v3
        with:
-         token: secrets.PERSONAL_TOKEN
+         token: ${{ secrets.PERSONAL_TOKEN }}
          labels: dependencies,docker
          title: "New base version detected: Updating to latest"
          commit-message: Updating docker image hash to newest version

[Cameronsplaze]

oml yeah that did it haha. I was stuck on that for a while. Something small is better than GitHub changing schedules work completely I guess.

Thank you for all your help once again!

[alexander-schranz]

Hello 👋,

what is the best way to debug this issue I created a resuable github action here which configure the token: https://github.com/schranz-php-recipes/symfony-recipes-php/blob/main/.github/workflows/callable-watch.yml#L46-L57

It can be triggered by workflow_dispatch or schedule: https://github.com/schranz-php-recipes/symfony-recipes-php-contrib/blob/07daec6334ac645bc5faeaf7f5e424c79902e02f/.github/workflows/watch.yml#L3-L14

THe bot I added to the organisation and repository in both it have write permissions. The BOT_TOKEN is configured.

But the push is still failing:

https://github.com/schranz-php-recipes/symfony-recipes-php-contrib/actions/runs/3534934894/jobs/5932387019

Did I forget something specific?

---

Update: Found my issues did use secrets.BOT_TOKEN instead of secrets.token 🙈 .

Still would be nice if the action tells us if the required token is empty or not. #1321