How to Create GitHub Issues and Trigger Actions from a Workflow with Jinba

Summary

The core GitHub automation loop is: create an issue with GITHUB_CREATE_AN_ISSUE, verify it with GITHUB_LIST_REPOSITORY_ISSUES, trigger CI with GITHUB_ACTIONS_RUN, and fetch release notes with GITHUB_LIST_RELEASES.
Every GitHub action authenticates with a Personal Access Token that has repo scope; store it as GITHUB_TOKEN and pass it via config: token.
Prevent duplicate issues by listing existing issues first or setting update_existing: true when creating an issue.
Scheduled workflows can close stale issues, open recurring issues, trigger pipelines, and attach release notes; start with one repository before scaling.
Teams building GitHub-connected workflows can create and deploy them faster with Jinba Flow.

To open a GitHub issue from a Jinba workflow, use the GITHUB_CREATE_AN_ISSUE action with config: token set to a Personal Access Token and input parameters for owner, repository, title, and body. Once the issue exists, read it back with GITHUB_LIST_REPOSITORY_ISSUES. The same workflow can then trigger a CI pipeline via GITHUB_ACTIONS_RUN and pull release notes with GITHUB_LIST_RELEASES.

This guide covers each step in that sequence. It does not cover pull request creation: the Jinba GitHub toolset handles issues, Actions runs, and releases, not PRs.

Step 1: Generate a GitHub Personal Access Token

Every Jinba action that touches GitHub authenticates with a Personal Access Token. The token identifies the GitHub account performing the action and the repositories it can access. Without it, none of the actions in this guide will run.

To generate one:

Open GitHub Settings, then go to Developer settings > Personal access tokens > Tokens (classic).
Click Generate new token.
Give the token a descriptive name, such as jinba-workflow-automation.
Set an expiration date.
Select the repo scope. This grants read and write access to issues, Actions, and releases.
Click Generate token.
Copy the token immediately. GitHub does not display it again after navigating away from the page.

Store the token as a secret named GITHUB_TOKEN in the workflow environment. Pass it to each action as config: token. GitHub's documentation on creating a personal access token covers the full process.

Step 2: Create an Issue with `GITHUB_CREATE_AN_ISSUE`

GITHUB_CREATE_AN_ISSUE is the core action for GitHub automation in Jinba. It calls the GitHub Issues API and opens a new issue in the specified repository.

The required inputs are:

config: token: the PAT, stored as GITHUB_TOKEN
input: owner: the GitHub username or organisation that owns the repository
input: repository: the repository name
input: title: the issue title
input: body: the issue description

A basic Jinba step looks like this:

- action: GITHUB_CREATE_AN_ISSUE
config:
token: "{{ secrets.GITHUB_TOKEN }}"
input:
owner: "your-org"
repository: "your-repo"
title: "Automated issue from Jinba workflow"
body: |
This issue was created automatically by a Jinba workflow.
Triggered by: {{ trigger.source }}

Dynamic values from the workflow context, such as {{ trigger.source }}, are substituted at runtime. This makes the same step reusable across different triggers without editing the YAML each time.

For teams that run recurring tasks, the GitHub Actions scheduled issue example shows how a cron schedule combined with the GitHub CLI can close the previous week's issue and open a fresh one automatically. The same pattern applies inside a Jinba workflow when the workflow trigger supplies the schedule.

The create-an-issue action on GitHub Marketplace documents additional optional inputs including assignees, labels, milestone, and update_existing. Set update_existing: true to update an open issue that shares the same title, rather than opening a duplicate.

Step 3: Verify the Issue with `GITHUB_LIST_REPOSITORY_ISSUES`

After GITHUB_CREATE_AN_ISSUE completes, use GITHUB_LIST_REPOSITORY_ISSUES to confirm the issue exists and to capture its number for use in later steps.

- action: GITHUB_LIST_REPOSITORY_ISSUES
config:
token: "{{ secrets.GITHUB_TOKEN }}"
input:
owner: "your-org"
repository: "your-repo"

The action returns an array of open issues. Each entry includes the issue number, title, URL, assignees, labels, and state. The issue number is the value passed to downstream steps: it identifies which issue a CI run or a release note summary should reference.

Tracking issue state through this action also addresses a common operational problem. When the same workflow runs repeatedly, listing existing issues before creating a new one allows operations teams to check whether an equivalent issue is already open. Platforms that manage multiple repositories find this check necessary to avoid duplicate issues accumulating without review.

Step 4: Trigger a CI Pipeline with `GITHUB_ACTIONS_RUN`

Once an issue is open, GITHUB_ACTIONS_RUN triggers a GitHub Actions workflow on the same or a different repository. The most reliable entry point is a workflow configured with the workflow_dispatch event, which accepts explicit inputs and runs on demand.

- action: GITHUB_ACTIONS_RUN
config:
token: "{{ secrets.GITHUB_TOKEN }}"
input:
owner: "your-org"
repository: "your-repo"
workflow_id: "ci.yml"
ref: "main"
inputs:
issue_number: "{{ steps.create_issue.outputs.number }}"

The inputs block passes data from earlier steps into the triggered workflow. Passing the issue number allows the CI job to label its results with the correct issue reference, or post a comment back to the issue when the run completes.

This pattern is useful in microservices environments where a single Jinba workflow coordinates activity across several repositories. A bug report in one service repository can trigger an integration test workflow in a shared infrastructure repository without a developer manually queuing the run. The workflow manages the handoff.

GITHUB_ACTIONS_RUN returns the run ID. Poll the run status using the same token to determine whether the triggered workflow succeeded before proceeding to the next step.

Step 5: Fetch Release Notes with `GITHUB_LIST_RELEASES`

GITHUB_LIST_RELEASES retrieves the releases associated with a repository. Teams use this to pull the latest release notes into a weekly summary issue or a status report without manually reading the GitHub UI.

- action: GITHUB_LIST_RELEASES
config:
token: "{{ secrets.GITHUB_TOKEN }}"
input:
owner: "your-org"
repository: "your-repo"

The action returns an ordered list of releases, each including the tag name, release name, body, publication date, and whether the release is a draft or pre-release. Pass the body of the most recent release into a subsequent GITHUB_CREATE_AN_ISSUE step to open a release notes issue automatically after each deployment.

The GitHub REST API reference for releases documents the full response structure and available filters. Additional endpoints for creating a release and generating release notes content extend this pattern if the workflow also manages the release itself.

Putting It Together: A Recurring Issue Workflow

The following example combines all five steps into a scheduled workflow that opens a weekly team sync issue, triggers a preparation checklist pipeline, and attaches the latest release notes to the issue body. It also closes the previous week's issue to keep the repository backlog clean.

name: Weekly Team Sync
on:
schedule:
- cron: '20 07 * * 1' # Every Monday at 07:20 UTC
jobs:
weekly_sync:
runs-on: ubuntu-latest
permissions:
issues: write
steps:
- name: Close previous sync issue
run: |
previous=$(gh issue list --label "weekly-sync" --json number --jq '.[0].number')
if [[ -n $previous ]]; then
gh issue close "$previous"
fi
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
GH_REPO: ${{ github.repository }}

- name: Create this week's sync issue
run: |
gh issue create \
--title "Team sync: week of $(date +%Y-%m-%d)" \
--label "weekly-sync" \
--assignee "monalisa,doctocat" \
--body "$BODY"
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
GH_REPO: ${{ github.repository }}
BODY: |
### Agenda
- [ ] Check-ins
- [ ] Discussion points
- [ ] Action items

This script uses the GitHub CLI. The cron expression sets the schedule: 20 07 * * 1 means 07:20 UTC on Mondays. The permissions block grants issues: write at the job level, which is the minimum required to open and close issues. Environment variables hold the configurable values: title, labels, assignees, and body. Changing any of those requires editing the env block, not the script logic.

The CLOSE_PREVIOUS pattern, implemented here as a shell conditional, prevents stale issues from accumulating. The workflow lists open issues with the weekly-sync label, takes the first result, and closes it before creating the new one.

In a Jinba context, the same logic runs as a sequence of GITHUB_LIST_REPOSITORY_ISSUES, GITHUB_CREATE_AN_ISSUE, and GITHUB_ACTIONS_RUN steps, with the workflow trigger set to a schedule rather than a manual dispatch.

What to Watch Next

The five actions covered here, GITHUB_CREATE_AN_ISSUE, GITHUB_LIST_REPOSITORY_ISSUES, GITHUB_ACTIONS_RUN, and GITHUB_LIST_RELEASES, cover the most common github automation needs: structured issue creation, status verification, pipeline triggering, and release tracking. Each action is composable, so the output of one step becomes the input of the next without manual intervention.

Platforms managing multiple repositories should start with a single workflow that covers one repository end to end before extending the pattern. Confirm that the PAT has repo scope on every repository the workflow touches, and set a token expiration date with a calendar reminder to rotate it.

For teams that want to expand beyond these actions, the GitHub Marketplace lists community-built actions covering labelling, project board updates, and notification routing. The GitHub CLI documentation at cli.github.com is the reference for scripting more complex issue management logic directly in a workflow step.

Frequently Asked Questions

What is the `GITHUB_CREATE_AN_ISSUE` action in Jinba?

GITHUB_CREATE_AN_ISSUE is a Jinba action that creates a new issue in a specified GitHub repository via the GitHub Issues API. It requires a Personal Access Token and input parameters for owner, repository, title, and body. The action automates issue creation directly from a workflow, making it suitable for reporting errors, scheduling recurring tasks, or capturing handoffs between services.

How do I authenticate a Jinba workflow with GitHub?

Jinba workflows authenticate to GitHub using a Personal Access Token (PAT) passed as config: token in each GitHub action. The token must have the repo scope to access issues, Actions, and releases. Store the token as a secret (e.g., GITHUB_TOKEN) in the workflow environment and reference it as {{ secrets.GITHUB_TOKEN }} to keep credentials out of source control.

How can I prevent duplicate issues in automated workflows?

To avoid duplicates, use GITHUB_LIST_REPOSITORY_ISSUES to check for existing open issues before creating a new one. Issues can be matched on title, labels, or other criteria. Alternatively, when using GITHUB_CREATE_AN_ISSUE, set update_existing: true to update an open issue with the same title instead of creating a duplicate. This is especially important for scheduled workflows that run repeatedly.

How do I trigger a GitHub Actions workflow from Jinba?

Use the GITHUB_ACTIONS_RUN action. Provide the owner, repository, workflow_id (e.g., ci.yml), and a ref (branch or tag). To pass data from earlier steps, include an inputs block, such as issue_number. The target workflow must be configured with the workflow_dispatch event to accept manual triggers.

What is the difference between Jinba GitHub actions and GitHub CLI?

Jinba GitHub actions are declarative steps inside a workflow that call GitHub APIs directly, while GitHub CLI (gh) is a command-line tool used in shell scripts within a workflow step. Jinba actions are more structured and composable, with outputs that can be passed to later steps automatically. GitHub CLI offers more granular control but requires writing and maintaining shell logic.

How do I pass data between steps in a Jinba workflow?

Jinba actions return outputs that can be referenced in later steps using the steps context. For example, after creating an issue, the issue number can be referenced with {{ steps.create_issue.outputs.number }}. Similarly, GITHUB_ACTIONS_RUN returns a run ID. This allows linking issues, CI runs, and releases in a single workflow.

Can I update an existing GitHub issue from Jinba instead of creating a new one?

Yes. The GITHUB_CREATE_AN_ISSUE action supports an optional update_existing input. Set update_existing: true to update an open issue that shares the same title. This is useful for recurring reports or daily summaries where a single issue should remain up to date rather than opening a new one each time.

How do I schedule a Jinba workflow to run automatically?

A Jinba workflow can be triggered on a schedule using a cron expression in the workflow's trigger configuration, similar to GitHub Actions scheduled events. For example, cron: '20 07 * * 1' runs every Monday at 07:20 UTC. Within the workflow, GitHub actions such as GITHUB_LIST_REPOSITORY_ISSUES and GITHUB_CREATE_AN_ISSUE then automate recurring tasks.

How do I fetch release notes from GitHub using Jinba?

Use the GITHUB_LIST_RELEASES action with a token and repository details. The action returns an ordered list of releases including tag name, body, and publication date. The body of the most recent release can then be passed to a subsequent GITHUB_CREATE_AN_ISSUE step to automatically generate a release notes issue after each deployment.