Time-Saving Automations: Keeping Jira in Sync with GitHub Pull Requests

Why automate Jira updates at all

Manually updating Jira as a pull request moves through review is repetitive and easy to forget. Opening Jira to move a ticket to Code Review, then updating it again after approval, and finally moving it to Done after the merge adds unnecessary context switching to the development workflow.

What this automation does

This automation keeps Jira in sync with GitHub pull requests automatically, so ticket status reflects real progress without manual effort.

The idea is simple. As a pull request moves through its lifecycle in GitHub, the linked Jira ticket should move through corresponding states. When a pull request is opened, the ticket moves to Code Review. When the pull request is approved, the ticket moves to Code Review Completed. When the pull request is merged, the ticket moves to Done.

One simple rule that enables everything

To make this possible, Jira tickets must be identifiable from GitHub activity. The simplest and most reliable approach is to include the Jira issue key in the pull request title. For example, a pull request titled ENG-123 Add login validation. This single convention allows every GitHub event to be mapped back to the correct Jira issue.

Check your Jira workflow before automating

Before automating anything, it is important to verify that Jira allows these transitions. Open a Jira issue and click the status dropdown. The options you see represent valid transitions from the current state. If Code Review or Done is not visible, automation should not attempt to move the issue to that state.

Jira does not accept status names in its API. It only accepts workflow transition IDs. Each transition has an ID, and that ID is what automation must use. Transition IDs are not visible in the Jira UI, so they must be retrieved using the Jira REST API.

How to find the correct transition ID

To find transition IDs, call the transitions endpoint for an issue while it is in a specific status.

curl -u your-email@company.com:YOUR_JIRA_API_TOKEN \
  -H "Accept: application/json" \
  https://your-domain.atlassian.net/rest/api/3/issue/PA-123/transitions

This response returns all transitions allowed from the issue’s current status. Each transition includes an ID and a target status. For example, when the issue is in In Progress, the response may include transitions that move it to Code Review or Done. When the issue is already in Code Review, the available transitions may be different.

Get Prateek Agnihotri’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Each transition ID is contextual. The same issue will expose different transitions depending on its current state. Automation must respect this and should never assume that a transition is always available.

How the automation workflow works

With transition IDs identified, the workflow becomes event-driven. GitHub Actions listens to pull request events and moves the Jira ticket accordingly.

When a pull request is opened, the workflow extracts the Jira key from the pull request title and calls the Jira API using the transition ID that moves the issue to Code Review.

When a pull request receives approval, the workflow again extracts the Jira key and applies the transition that moves the issue to Code Review Completed.

When the pull request is merged, the workflow applies the transition that moves the issue to Done.

Below is a simplified example using pull request open and merge events. The same pattern can be extended to approval events.

name: Sync Jira with Pull Request lifecycle
on:
  pull_request:  
    types: [opened, closed]

jobs:
  jira-sync:
    runs-on: ubuntu-latest
    steps:
      - name: Extract Jira key
        run: |
          echo "JIRA_KEY=$(echo '${{ github.event.pull_request.title }}' | grep -o '[A-Z]\+-[0-9]\+')" >> $GITHUB_ENV
      - name: Move Jira issue to Code Review on PR open
        if: github.event.action == 'opened' && env.JIRA_KEY != ''
        run: |
          curl -X POST \
            -u ${{ secrets.JIRA_EMAIL }}:${{ secrets.JIRA_API_TOKEN }} \
            -H "Content-Type: application/json" \
            https://your-domain.atlassian.net/rest/api/3/issue/${{ env.JIRA_KEY }}/transitions \
            -d '{
              "transition": {
                "id": "21"
              }
            }'
      - name: Move Jira issue to Done on PR merge
        if: github.event.action == 'closed' && github.event.pull_request.merged == true && env.JIRA_KEY != ''
        run: |
          curl -X POST \
            -u ${{ secrets.JIRA_EMAIL }}:${{ secrets.JIRA_API_TOKEN }} \
            -H "Content-Type: application/json" \
            https://your-domain.atlassian.net/rest/api/3/issue/${{ env.JIRA_KEY }}/transitions \
            -d '{
              "transition": {
                "id": "31"
              }
            }'

In this example, transition ID 21 represents the move to Code Review, and transition ID 31 represents the move to Done. These IDs must be replaced with the correct ones from your Jira workflow.

At a high level, the flow works like this. A developer opens a pull request. Jira moves the ticket to Code Review automatically. The pull request is reviewed and approved. The ticket can be moved to Code Review Completed using the same pattern. When the pull request is merged, the ticket moves to Done. Jira stays accurate without manual updates.

This setup saves time by eliminating repeated Jira updates, reducing context switching, and ensuring that ticket status reflects real development progress. Developers stay in GitHub, and Jira updates itself.

Final thoughts

Automation should always follow the workflow, not override it. If a transition is not allowed from a given state, the automation should skip it silently. The goal is to save time while preserving trust in the system.

With one naming convention, a few transition IDs, and a small GitHub workflow, Jira can stay in sync with development activity automatically. This is a simple automation, but it saves time every single day.