push workflow not triggered in v3.

[JamesKyburz]

Prerequisites

• I have written a descriptive issue title
• I have searched existing issues to ensure the regression has not already been reported

Last working version

2.x

Stopped working in version

3.x

Node.js version

12.x

Operating system

Linux

Operating system version (i.e. 20.04, 11.3, 10)

20.04

💥 Regression Report

Now that v3 directly merges the pull request in the workflow without using an external app no push workflow is triggered.

In v2 once a dependabot pull request got merged any workflows listening on the push event were triggered.

Steps to Reproduce

automerge.yml

name: automerge

on:
  pull_request:
    branches:
      - main

jobs:
  automerge:
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
      contents: write
    if: ${{ github.actor == 'dependabot[bot]' }}
    steps:
      - uses: fastify/github-action-merge-dependabot@v3.0.2
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}

ci.yml

name: ci

on:
  push:
    branches:
      - main

jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo hello

Expected Behavior

ci.yml to be called.

I am unsure how/if this can be fixed as dependabot workflows have no access to other secrets other than the default GITHUB_TOKEN.

[simoneb]

Thanks for reporting this. I'm afraid that we simply did not consider this when moving away from the backing web app, which we thought of as a temporary workaround for limitations in github permissions.

I think that the behavior you're seeing is another known limitation in github, which prevents workflows to trigger other workflows to avoid infinite recursion.

This is a somewhat important limit that we should probably point out in the docs, but I don't see us going back to the backing web app at this stage.

[simoneb]

including @Eomm in this conversation

[Eomm]

As workaround, could you try to use a custom developer token instead of the default GITHUB_TOKEN?

[simoneb]

together with @Eomm's suggestion above, and regarding your comment:

I am unsure how/if this can be fixed as dependabot workflows have no access to other secrets other than the default GITHUB_TOKEN.

GitHub now supports dependabot secrets. So storing a PAT in secrets AND dependabot secrets would probably make this work.

It's not a full solution, but it may be the best we can do for now, apart from staying on v2.

[mcollina]

Now that v3 directly merges the pull request in the workflow without using an external app no push workflow is triggered.

This seems a limitation/bug in Github Actions. New commits are pushed to main so I would have expected the workflow to run. Maybe we should open an issue there?

[JamesKyburz]

I will check if a PAT works using a Dependabot secret, if so maybe we could just update the README to reflect the v3 changes.

[JamesKyburz]

It does work with a dependabot specific repository secret PAT :) Also if this is used then you don't need to specify extra permissions because the rights given by the PAT.

[simoneb]

Thanks for trying this out @JamesKyburz . The main issues with PATs are the lack of permission granularity and that they are bound to a user, which make them inappropriate for repositories with multiple contributors. I would personally not be comfortable using them in a repository with multiple contributors. On the other hand, I don't think there are any other solutions which would cause the merged PRs to trigger other workflows.

[JamesKyburz]

@simoneb I agree, although I can't think of any other solution either. I am also yet to find a way to automatically rotate PAT secrets too ☹️

[Eomm]

After reading the GH docs it seems not doable by setting some config.

Maybe we could add an extra step to trigger a workflow by calling the /repos/{owner}/{repo}/actions/workflows/{workflow_id}/dispatches API to trigger a workflow manually

[simoneb]

We would need to configure which workflow(s) to trigger. I am not a fan of the idea but not against it either. For most practical purposes this unintended behavior we have is surely not nice but not an extremely big deal anyway in my opinion (especially because we don't really have many options outside of going back to the backing github app).

The reason why it's not a very big deal in my opinion is because usually we would configure whatever workflow we run when something is merged to the master/main branch to run both on push and pull_request events, meaning that when you're in a dependabot PR, you're already running those same workflows for both the code that's in the PR and the code that's the result of merging the PR's branch into master/main, meaning that another workflow(s) run when the PR is actually merge is largely redundant.

Now, I appreciate this is not certainly covering all scenarios (e.g. you're triggering a CD workflow when merging to master/main), but lacking an obvious solution I guess we have to accept that we have this limitation, unless we decide that we don't want to have it, in which case the most obvious option is to go back to the github app.

[tinohager]

Hi, I just stumbled across this problem too and from my point of view I would have no problem specifying the workflow I want to call. Is there an implementation date for the function?

[tinohager]

I have found a solution for my workflow issue, my pull request workflow has this name Check Pull Request

Add this to the workflow to be executed after the pull request workflow

on:
  workflow_run:
    workflows: ["Check Pull Request"]
    types:
      - completed

[Eomm]

Hi, I just stumbled across this problem too and from my point of view I would have no problem specifying the workflow I want to call. Is there an implementation date for the function?

There is nobody working on it. Would you like to send a PR?

I have found a solution for my workflow issue

do you mean something like the following?

name: ci

on:
  push:
    branches:
      - main
  workflow_run:
    workflows: ["automerge"]
    types:
      - completed

jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo hello

It seems a good solution to me: we could document it!

[simoneb]

My only doubt here is that we have normally used exactly the same workflow for CI containing both our CI steps and the step which invokes the automerge action. This solution implies that the two would have to live in different workflow files. Let's say you have a ci and an automerge workflows. What triggers what?

pull_request -> ci
ci -> automerge
automerge -> ci

This goes into an infinite loop, doesn't it?