---
title: "The github_actions action is deprecated"
date: 2026-07-29
tags:
  - Workflow Automation
  - Deprecations
description: "The github_actions workflow automation action is deprecated and will be removed on 31 March 2027. Trigger your workflows from GitHub Actions directly with on: pull_request, workflow_dispatch, or repository_dispatch instead."
---

The `github_actions` action in `pull_request_rules` is deprecated. It keeps working until **31 March 2027**, after which it is removed.

If you use it, you will now see a deprecation notice in the Mergify check run on your pull requests, and a *Deprecated* badge on the action in the dashboard editor. Nothing else changes: your workflows are still dispatched exactly as before.

## Why

Everything this action does can be done by GitHub Actions itself, without Mergify in the middle. Triggering your workflow natively means one fewer moving part between a pull request event and the workflow that reacts to it.

## What to use instead

Most rules using this action react to something that already has a native GitHub trigger. A rule that runs a workflow after a merge:

```yaml
pull_request_rules:
  - name: trigger JIRA transition
    conditions:
      - merged
    actions:
      github_actions:
        workflow:
          dispatch:
            - workflow: jira-transition.yaml
```

becomes a trigger on the workflow itself:

```yaml
# .github/workflows/jira-transition.yaml
on:
  pull_request:
    types: [closed]

jobs:
  transition:
    if: github.event.pull_request.merged
    runs-on: ubuntu-latest
    steps:
      # ...
```

When the workflow has to be triggered explicitly rather than by a pull request event, use `workflow_dispatch` or `repository_dispatch`.

One thing does not carry across automatically: Mergify conditions. If your rule used conditions to decide whether the workflow should run, express that logic inside the workflow — as an `if:` on the job, or as a filter on the trigger.

[Documentation](https://docs.mergify.com/workflow/actions/github_actions)