Short answer: Drop the "GitHub → Create Release" action anywhere in your workflow, map the inputs from upstream nodes, and publish.
Every field can be mapped from an upstream trigger, AI step, table row, or hard-coded literal.
| Field | Type | Required | Description |
|---|---|---|---|
Repository Owner owner | string | Required | GitHub repository owner — the user or organization login (the part before / in owner/repo URLs). |
Repository Name repo | string | Required | GitHub repository name — the part after / in owner/repo URLs. Not the full URL. |
Tag Name tag_name | string | Required | Tag Name. Example: v1.2.0 |
Release Title name | string | Required | Release Title. Example: v1.2.0 — Bug fixes and improvements |
Release Notes body | string | Optional | Markdown release notes |
Draft draft | options | Optional | Draft. Options: No, Yes |
Pre-release prerelease | options | Optional | Pre-release. Options: No, Yes |
Target Branch/Commit target_commitish | string | Optional | Branch or commit SHA to tag. Defaults to default branch. |
{"owner": "e.g. acme-corp","repo": "e.g. my-project","tag_name": "e.g. v1.2.0","name": "e.g. v1.2.0 — Bug fixes and improvements","body": "## What's Changed\n- Fixed login redirect\n- Improved performance"}
{"id": 1,"name": "v1.2.0","draft": false,"html_url": "https://github.com/acme/my-project/releases/tag/v1.2.0","tag_name": "v1.2.0"}
Use these fields in downstream nodes for routing, logging, or error handling.
Any of these apps can fire this action as part of a workflow.
Triggered by anything in the catalog. Free tier available. No credit card.