Cyclic workflow, is it possible?

Hi,
I’m considdering switching from Travis CI from GH Actions and I am exploring what GHA provides.
I got a workflow for several repositories (dozens) that deals with automatic updates in this way:

  • A bot runs a cronjob, fetches my repositories, fetches updates, pushes a new branch with the updates, and opens pull requests.
  • The CI should start, check if the update works
  • Once the CI is complete, if the checks were successful, then I use the automerge action to rebase updates automatically in the development branch (the temporary branch is deleted upon rebase)

In case there are updates on the development branch, the automerge action rebases the branch and force-pushes it. In this case, the CI should restart.
This also captures the case in which there are concurrent updates: the first that gets merged causes a re-evaluation of further updates.

This workflow used to work flawlessly with Travis CI. I am having difficulties into reimplementing it with GH actions, though. It looks like that upgrades coming from force-pushes on update branches are not considered for CI. In turn, then, the automerge action does not trigger, as it is configured to start when repository checks are complete.

What is the right way to configure such workflow with GHA?

1 Like

I assume you’re using the GITHUB_TOKEN to push the updates created in the cron job? There’s a limitation to that, see Using the GITHUB_TOKEN in a workflow:

When you use the repository’s GITHUB_TOKEN to perform tasks on behalf of the GitHub Actions app, events triggered by the GITHUB_TOKEN will not create a new workflow run. This prevents you from accidentally creating recursive workflow runs.

To get around that limitation you’ll need to create a PAT (personal access token) with the required permissions and use that instead (via Secrets).

3 Likes

Thank you! That was exactly the reason!

1 Like