GitHub to GitLab, release issues created for you
Releases ship, and then the follow-up work gets… fuzzy. Someone has to open a tracking issue, paste the changelog link, tag the right owner, and make sure it doesn’t get duplicated when two people notice the same release.
Product Managers feel it when rollout tasks slip. Engineering leads get pulled into “who owns this?” threads. And agency teams managing several client repos end up doing the same GitHub GitLab integration busywork again and again.
This workflow turns every GitHub release into a GitLab issue (with duplicate checks). You’ll see how it works, what you need, and where teams usually trip up when they automate release follow-through.
How This Automation Works
See how this solves the problem:
n8n Workflow Template: GitHub to GitLab, release issues created for you
flowchart LR
subgraph sg0["Flow 1"]
direction LR
n0["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/github.dark.svg' width='40' height='40' /></div><br/>Fetch Newest Release"]
n1@{ icon: "mdi:cog", form: "rounded", label: "Scheduled Weekly Trigger", pos: "b", h: 48 }
n2["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/merge.svg' width='40' height='40' /></div><br/>Combine Streams"]
n3@{ icon: "mdi:code-braces", form: "rounded", label: "Validate Release Issue", pos: "b", h: 48 }
n4["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/gitlab.svg' width='40' height='40' /></div><br/>Generate Issue Ticket"]
n5["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/gitlab.svg' width='40' height='40' /></div><br/>Retrieve Repo Issues"]
n1 --> n0
n1 --> n5
n2 --> n3
n5 --> n2
n0 --> n2
n3 --> n4
end
%% Styling
classDef trigger fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
classDef ai fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
classDef aiModel fill:#e8eaf6,stroke:#3f51b5,stroke-width:2px
classDef decision fill:#fff8e1,stroke:#f9a825,stroke-width:2px
classDef database fill:#fce4ec,stroke:#c2185b,stroke-width:2px
classDef api fill:#fff3e0,stroke:#e65100,stroke-width:2px
classDef code fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
classDef disabled stroke-dasharray: 5 5,opacity: 0.5
class n3 code
classDef customIcon fill:none,stroke:none
class n0,n2,n4,n5 customIcon
The Challenge: Release Follow-Through Falls Through the Cracks
A GitHub release is a clear moment in time. The work after it usually isn’t. You might need to update docs, notify customers, coordinate a deployment window, or track a hotfix. But if creating the “release tracking” issue is manual, it becomes inconsistent: sometimes it’s done, sometimes it’s late, and sometimes two people create two different tickets for the same release. Then you get the worst kind of overhead. Not productive work, just cleanup work.
It adds up fast. Here’s where it breaks down in real teams.
- Someone has to notice the release and remember to open a GitLab issue, which often happens hours (or days) later.
- Duplicate rollout tickets get created when multiple people “helpfully” track the same release in parallel.
- Details end up scattered across Slack/Teams, release pages, and issue comments, so owners waste time hunting for context.
- When you manage several repos, the mental load spikes because every repo has a slightly different release rhythm and checklist.
The Fix: GitHub Releases Automatically Become GitLab Issues
This n8n workflow runs on a schedule and checks a GitHub repository for the newest release. At the same time, it pulls the current list of GitLab issues for the target project so it can sanity-check what already exists. Those two streams are merged, and a small validation step looks for a matching “release issue” so you don’t spam your project with duplicates. If the release is new, the workflow creates a fresh GitLab issue that your team can assign, label, and track like any other piece of work. You get consistent follow-through without needing someone to “own” the admin.
The workflow starts with a weekly Cron trigger (you can change the cadence). GitHub provides the latest release data, GitLab provides the existing issue list, and the Function step decides if this release already has a ticket. Finally, the GitLab node creates the issue only when it’s truly needed.
What Changes: Before vs. After
| What This Eliminates | Impact You’ll See |
|---|---|
|
|
Real-World Impact
Say you manage 5 repos and do weekly releases. Manually, you might spend about 10 minutes per repo checking for a release and another 10 minutes creating a decent GitLab ticket, so roughly 1.5 hours a week. With this workflow, the Cron trigger runs in the background and the only “human time” is skimming the newly created issue, maybe 2 minutes per repo. That’s about an hour back most weeks, and the bigger win is that nothing gets missed.
Requirements
- n8n instance (try n8n Cloud free)
- Self-hosting option if you prefer (Hostinger works well)
- GitHub to read the latest release data.
- GitLab to retrieve issues and create new ones.
- GitHub and GitLab API credentials (create tokens in each account’s access token settings).
Skill level: Beginner. You’ll mostly paste API tokens, set repo/project IDs, and test once.
Need help implementing this? Talk to an automation expert (free 15-minute consultation).
The Workflow Flow
Weekly schedule kicks it off. The Cron node runs on your chosen cadence, which is useful when you can’t (or don’t want to) rely on a GitHub webhook.
GitHub and GitLab data are pulled in parallel. One path fetches the newest GitHub release, while the other retrieves existing GitLab issues for the target repo/project so the workflow has something to compare against.
Duplicate checking happens before anything is created. The Merge node combines both streams, and the Function node validates whether a release-tracking issue already exists for that release.
A GitLab issue is created only when needed. If validation passes, the workflow generates a new issue ticket in GitLab, ready for labels, assignees, and your rollout checklist.
You can easily modify the schedule to run daily instead of weekly based on your release cadence. See the full implementation guide below for customization options.
Step-by-Step Implementation Guide
Step 1: Configure the Scheduled Trigger
This workflow runs on a weekly schedule to check for new releases and existing issues.
- Add the Scheduled Weekly Trigger node as your trigger.
- Set Mode to
everyWeekin triggerTimes. - Confirm that Scheduled Weekly Trigger outputs to both Fetch Newest Release and Retrieve Repo Issues in parallel.
Scheduled Weekly Trigger outputs to both Fetch Newest Release and Retrieve Repo Issues in parallel.
Step 2: Connect Release and Issue Data Sources
These nodes fetch the latest GitHub release and existing GitLab issues for comparison.
- Configure Fetch Newest Release with Resource set to
releaseand Operation set togetAll. - Set Limit to
1in Fetch Newest Release to only fetch the latest release. - Configure Retrieve Repo Issues with Resource set to
repository, Owner set totxlab, and Repository set todocker-linkcheck. - Credential Required: Connect your GitHub credentials in Fetch Newest Release.
- Credential Required: Connect your GitLab credentials in Retrieve Repo Issues.
⚠️ Common Pitfall: If GitHub or GitLab credentials are missing, the workflow will fail before reaching the merge step.
Step 3: Merge Parallel Data Streams
Combine the release and issue datasets to prepare for validation.
- Add the Combine Streams node and connect Fetch Newest Release to input 0.
- Connect Retrieve Repo Issues to input 1 of Combine Streams.
- Ensure Combine Streams outputs to Validate Release Issue.
Step 4: Set Up Release Validation Logic
The validation checks whether an issue already exists for the latest release.
- Add the Validate Release Issue node after Combine Streams.
- Paste the full functionCode into Validate Release Issue:
- Use this code exactly:
const _ = require('lodash')\n\n// differentiate merged inputs (didnt find a way to get both inputs into one function invocation)\nconst releases = _.filter(items, i => _.has(i, 'json.assets'))\nif (releases.length != 1) throw new Error(`Invalid release count: ${releases.length}`)\nconst release = releases[0]\nconst issues = _.without(items, release)\n//console.log({release,issues})\n\n// check if there's an issue for the release\nconst matchingIssue = _.find(issues, i => i.json.title.includes(release.json.tag_name))\n//console.log({release,issues,matchingIssue})\n\nif (matchingIssue)\n return []\nelse\n return [release]
⚠️ Common Pitfall: If the merged inputs are missing the release or issues, the function will throw Invalid release count.
Step 5: Configure Issue Creation Output
Create a new GitLab issue only when no matching issue exists for the release.
- Add Generate Issue Ticket after Validate Release Issue.
- Set Owner to
txlaband Repository todocker-linkcheck. - Set Title to
=Upstream release: {{$json["tag_name"]}}. - Set Body to
={{$json["url"]}}\n\n{{$json["body"]}}. - Credential Required: Connect your GitLab credentials in Generate Issue Ticket.
Step 6: Test & Activate Your Workflow
Validate the workflow end-to-end before enabling the weekly schedule.
- Click Execute Workflow to run manually and confirm both branches complete and merge into Combine Streams.
- Verify that Validate Release Issue outputs an item only when a release has no matching issue.
- Check GitLab to confirm a new issue is created by Generate Issue Ticket with the expected title and body.
- Once confirmed, toggle Active to enable the weekly schedule.
Watch Out For
- GitLab credentials can expire or need specific permissions. If things break, check your GitLab Access Tokens (scope and expiration) first.
- If you’re using Wait nodes or external rendering, processing times vary. Bump up the wait duration if downstream nodes fail on empty responses.
- Default prompts in AI nodes are generic. Add your brand voice early or you’ll be editing outputs forever.
Common Questions
Usually about 30 minutes if you already have tokens and repo details.
Yes. No coding is required. You’ll connect GitHub and GitLab, then paste in the repo/project identifiers.
Yes. n8n has a free self-hosted option and a free trial on n8n Cloud. Cloud plans start at $20/month for higher volume. You’ll also need to factor in GitHub and GitLab access (typically free) and any paid GitLab tier your team already uses.
Two options: n8n Cloud (managed, easiest setup) or self-hosting on a VPS. For self-hosting, Hostinger VPS is affordable and handles n8n well. Self-hosting gives you unlimited executions but requires basic server management.
You can swap the Scheduled Weekly Trigger for a GitHub Trigger if you own the repo and can create webhooks. Most teams also customize the “Validate Release Issue” logic to match their naming style (for example, “Release v1.2.0” vs “Rollout: v1.2.0”), and then tweak “Generate Issue Ticket” to set labels, assignees, and a checklist template.
Usually it’s an expired token or missing scopes on the GitLab Access Token, so regenerate it and update the credential in n8n.
On n8n Cloud Starter, you can run a healthy number of executions per month for a small team, and upgrading increases that ceiling. If you self-host, there’s no platform execution cap, but your server size becomes the limiter. Practically, this workflow runs only on your schedule and touches a small set of records (one newest release plus the project’s issue list), so it’s lightweight. If you monitor dozens of repos daily, consider splitting by repo and staggering schedules to avoid API rate limits.
Often, yes. Duplicate checking is where simple “trigger → action” tools can get awkward, and n8n handles branching, merging, and validation logic cleanly without turning it into a fragile chain of Zaps. You also get the option to self-host, which matters when executions grow. Zapier or Make can still be fine for basic alerts. Talk to an automation expert if you want help choosing.
You ship the release. The workflow creates the tracking issue and keeps GitLab honest. Honestly, that small bit of automation is what makes “clean follow-through” feel normal again.
Need Help Setting This Up?
Our automation experts can build and customize this workflow for your specific needs. Free 15-minute consultation—no commitment required.
