Beginner~12 min setupDeveloper Tools & Project ManagementVerified April 2026

How to Generate Release Notes from GitHub to Jira with Make

Automatically update Jira tickets to Done when GitHub releases are published and compile release notes from ticket summaries.

Steps and UI details are based on platform versions at time of writing — check each platform for the latest interface.

Make

Also on:Zapier N8n Power-automate Pipedream

What Will This Cost?

Drag the slider to your expected monthly volume.

Monthly workflow runs

/mo

505005K50K

Each platform counts differently — Zapier: 1 task per trigger. Make: 1 operation per module per record. n8n: 1 execution per run.

$30/mo if billed monthly

Pipedream

$29/mo

Basic plan

Prices shown for annual billing. Based on published pricing as of April 2026.

Estimated ROI

1000

min saved/mo

$583

labor value/mo

Free

no platform cost

Based on ~2 min manual effort per operation at $35/hr fully loaded labor cost.

Implementation

Skip the setup

Import this workflow directly into Make

Copy the pre-built Make blueprint and paste it straight into Make. All modules, filters, and field mappings are already configured — you just need to connect your accounts.

Before You Start

Make sure you have everything ready.

GitHub personal access token with 'repo' permissions

Jira API token and admin access to update ticket status

Consistent Jira ticket referencing in Git commit messages

Jira workflow that allows transitioning tickets to Done status

GitHub repository with release tagging workflow established

Step-by-Step Setup

Scenarios > Create > GitHub > Watch Repository Events

Create new scenario and add GitHub webhook trigger

Set up Make to listen for GitHub release events. The webhook trigger fires instantly when a release is published, unlike polling triggers that check every 15 minutes.

1Click 'Create a new scenario' from the Make dashboard
2Click the large '+' circle to add your first module
3Search for 'GitHub' and select it from the app list
4Choose 'Watch Repository Events' as your trigger

✓ What you should see: You should see a GitHub module with 'Watch Repository Events' selected and a webhook URL generated.

⚠

Common mistake — Copy the webhook URL carefully — it expires if you regenerate it, and any scenarios using the old URL will silently stop working.

Make

click +

search apps

GitHub

Create new scenario and add …

GitHub

module added

GitHub Module > Connection Settings

Connect GitHub account and configure repository

Authenticate with GitHub using a personal access token. Make needs 'repo' permissions to read release data and access commit information.

1Click 'Create a connection' in the GitHub module
2Enter your GitHub username in the Username field
3Paste your personal access token in the Token field
4Select your target repository from the Repository dropdown
5Set Events to 'released' only

✓ What you should see: GitHub connection shows green 'verified' status and your repository appears in the dropdown list.

⚠

Common mistake — Don't select 'published' event - that includes drafts and pre-releases you don't want in production release notes.

Make settings

Connection

Choose a connection…Add

click Add

GitHub

Authorize Make

popup window

✓

Connected

green checkmark

Between modules > Filter > Conditions

Add filter to only process full releases

Filter out draft releases and pre-releases to avoid generating notes for incomplete releases. This prevents the automation from running on test releases.

1Click the wrench icon between modules to add a filter
2Name the filter 'Full Releases Only'
3Set condition: 'draft' equals 'false'
4Add second condition with AND: 'prerelease' equals 'false'

✓ What you should see: A filter icon appears between modules showing your conditions.

⚠

Common mistake — Use 'false' as text, not boolean - GitHub webhook sends strings, not true/false values.

GitHub

trigger

filter

Condition

matches criteria?

yes — passes through

no — skipped

Jira

notified

HTTP Module > Make a request

Add HTTP module to fetch GitHub commits

Get the commit list between releases to find Jira ticket references. GitHub's release webhook doesn't include commit details, so we need a separate API call.

1Click '+' after the filter to add a new module
2Select 'HTTP' from the module list
3Choose 'Make a request' action
4Set URL to: https://api.github.com/repos/{owner}/{repo}/compare/{previous_tag}...{current_tag}
5Set Method to GET and add Authorization header with your GitHub token

✓ What you should see: HTTP module configured with the GitHub API endpoint and proper authentication headers.

Text parser > Match pattern

Add text parser to extract Jira ticket IDs

Parse commit messages to find Jira ticket references using regex. Most teams reference tickets in commits like 'ABC-123: Fix user login issue'.

1Add 'Text parser' module after the HTTP request
2Select 'Match pattern' action
3Set Text to: commits[].commit.message from HTTP response
4Set Pattern to: ([A-Z]+\-[0-9]+)
5Enable 'Global match' to find all ticket references

✓ What you should see: Text parser shows a sample match with your Jira project key format like 'PROJ-123'.

⚠

Common mistake — Adjust the regex pattern to match your Jira project keys - some teams use numbers in project keys like 'PROJ1-123'.

Array aggregator > Source and Target

Add array aggregator for ticket IDs

Collect all unique Jira ticket IDs into a single array. Without aggregation, Make would process tickets one by one instead of as a batch.

1Add 'Array aggregator' module after text parser
2Set Source Module to the text parser
3Map 'Value' field to the matched pattern from text parser
4Leave Target structure type as 'Custom'
5Name the array field 'ticket_ids'

✓ What you should see: Aggregator module shows it will collect all matched ticket IDs into a single array.

Jira > Search for Issues

Connect to Jira and search for tickets

Authenticate with Jira and search for tickets using the extracted IDs. This gets the current ticket details and summaries for release notes.

1Add 'Jira' module after the array aggregator
2Select 'Search for Issues' action
3Create connection using your Jira domain and API token
4Set JQL query to: key in ({ticket_ids from aggregator})
5Set Fields to: summary,status,description

✓ What you should see: Jira connection verified and search query configured to find tickets by key.

⚠

Common mistake — Use your actual Jira domain format like 'yourcompany.atlassian.net' - don't include https:// in the domain field.

Iterator > Array source

Add iterator to process each ticket

Split the Jira search results into individual tickets for status updates. Each ticket needs to be updated separately to 'Done' status.

1Add 'Iterator' module after Jira search
2Set Array to: issues from Jira search results
3The iterator will process each ticket individually

✓ What you should see: Iterator shows it will process each issue from the Jira search results.

Jira > Update an Issue

Update Jira ticket status to Done

Transition each ticket to Done status when included in a release. This marks development work as complete in your project tracking.

1Add another 'Jira' module after the iterator
2Select 'Update an Issue' action
3Map Issue Key from iterator: key field
4Set Status to 'Done' or your workflow's completion status
5Leave other fields unchanged

✓ What you should see: Jira update module configured to transition tickets to Done status.

⚠

Common mistake — Check your Jira workflow - some projects use 'Completed' or 'Resolved' instead of 'Done' as the final status.

Array aggregator > Release notes format

Aggregate ticket summaries for release notes

Collect all ticket summaries into a formatted release notes document. This creates a readable changelog from Jira ticket titles.

1Add second 'Array aggregator' after Jira update
2Set Source Module to the iterator
3Map ticket summary and key fields
4Format as: '- {summary} ({key})'
5Name the target field 'release_notes'

✓ What you should see: Second aggregator configured to build formatted release notes from ticket summaries.

GitHub > Update a Release

Create GitHub release notes comment

Add the compiled release notes back to the GitHub release. This creates a permanent record of what was completed in each release.

1Add final 'GitHub' module after the aggregator
2Select 'Update a Release' action
3Map Release ID from the original webhook
4Set Body to the aggregated release_notes text
5Keep the original name and tag unchanged

✓ What you should see: GitHub update module ready to add release notes to the published release.

Scenario controls > Run once

Test the complete workflow

Run a full test with a real GitHub release to verify ticket updates and release notes generation. Testing with sample data won't catch API permission issues.

1Click 'Run once' at the bottom of the scenario
2Create a test release in GitHub with commits referencing Jira tickets
3Check that Jira tickets moved to Done status
4Verify release notes appeared in the GitHub release body
5Click 'Turn on' to activate the scenario

✓ What you should see: Scenario runs successfully, tickets update in Jira, and formatted release notes appear in GitHub.

⚠

Common mistake — Don't test on your main branch - create releases from a test branch to avoid accidentally updating production tickets.

Make

▶ Run once

executed

✓

GitHub

✓

Jira

🔔 notification

received

Going live

Troubleshooting

Common errors and how to fix them.

Analysis

VerdictWhy Make for this workflow

Use Make for this if you want visual workflow building and don't mind the learning curve. Make's iterator and aggregator modules handle the ticket processing and release notes compilation better than Zapier's limited data manipulation. The HTTP module gives you full control over the GitHub API calls needed to fetch commit data. Skip Make if your team needs this running within 10 seconds of release - go with a custom webhook script instead since Make adds 30-60 seconds of processing time.

Cost

This workflow burns about 12 operations per release: 1 for the trigger, 1 for HTTP request, 1 for text parsing, 2 for aggregation, 1 for Jira search, 3-5 for ticket updates (depends on ticket count), and 1 for GitHub update. At 10 releases per month, that's 120 operations total. Make's Core plan at $9/month includes 10,000 operations, so you're nowhere near the limit. Zapier would need the Starter plan at $20/month for the same webhook triggers and multi-step workflow. Make saves you $11 monthly here.

Tradeoffs

Zapier handles Jira authentication more smoothly - their OAuth setup takes 30 seconds versus Make's manual API token configuration. N8n gives you better error handling with try-catch blocks around each API call, so failed ticket updates don't break the entire workflow. But Make's visual debugging shows you exactly which ticket update failed and why, making troubleshooting faster when things break at 2am after a hotfix release.

You'll hit GitHub's commit comparison API limits if you have releases with 500+ commits between tags. The API paginates at 250 commits and Make's iterator handles pagination automatically, but you'll burn extra operations. Jira's JQL query has a 100-item limit for 'key in' searches, so massive releases need batch processing. Also, teams using squash merges lose individual commit messages, breaking the ticket extraction entirely.

Ideas for what to build next

→
Add error handling — Set up a fallback path that sends a Slack alert if the automation fails to run.
→
Build a daily digest — Instead of real-time notifications, batch events and post a daily summary.
→
Add a second action — Extend this workflow to also log data to a spreadsheet alongside sending the notification.