{"id":1846,"date":"2025-03-19T16:36:04","date_gmt":"2025-03-19T16:36:04","guid":{"rendered":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2025\/03\/19\/issueops-automate-ci-cd-and-more-with-github-issues-and-actions\/"},"modified":"2025-03-19T16:36:04","modified_gmt":"2025-03-19T16:36:04","slug":"issueops-automate-ci-cd-and-more-with-github-issues-and-actions","status":"publish","type":"post","link":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/2025\/03\/19\/issueops-automate-ci-cd-and-more-with-github-issues-and-actions\/","title":{"rendered":"IssueOps: Automate CI\/CD (and more!) with GitHub Issues and Actions"},"content":{"rendered":"

Software development is filled with repetitive tasks\u2014managing issues, handling approvals, triggering CI\/CD workflows, and more. But what if you could automate these types of tasks directly within GitHub Issues? That\u2019s the promise of IssueOps<\/strong>, a methodology that turns GitHub Issues into a command center for automation.<\/p>\n

Whether you\u2019re a solo developer or part of an engineering team, IssueOps helps you streamline operations without ever leaving your repository.<\/p>\n

In this article, I\u2019ll explore the concept of IssueOps using state-machine terminology and strategies to help you work more efficiently on GitHub. After all, who doesn\u2019t love automation?<\/p>\n

What is IssueOps?<\/a><\/h2>\n

IssueOps is the practice of using GitHub Issues, GitHub Actions, and pull requests (PR) as an interface for automating workflows. Instead of switching between tools or manually triggering actions, you can use issue comments, labels, and state changes to kick off CI\/CD pipelines, assign tasks, and even deploy applications.<\/p>\n

Much like the various other *Ops<\/em> paradigms (ChatOps<\/a>, ClickOps, and so on), IssueOps is a collection of tools, workflows, and concepts that, when applied to GitHub Issues<\/a>, can automate mundane, repetitive tasks. The flexibility and power of issues, along with their relationship to pull requests, create a near limitless number of possibilities, such as managing approvals and deployments. All of this can really help to simplify your workflows on GitHub. I\u2019m speaking from personal experience here.<\/p>\n

It\u2019s important to note that IssueOps isn\u2019t just a DevOps thing! Where DevOps offers a methodology to bring developers and operations into closer alignment, IssueOps is a workflow automation practice centered around GitHub Issues. IssueOps lets you run anything from complex CI\/CD pipelines<\/a> to a bed and breakfast reservation system<\/a>. If you can interact with it via an API, there\u2019s a good chance you can build it with IssueOps!<\/p>\n

So, why use IssueOps?<\/a><\/h2>\n

There are lots of benefits to utilizing IssueOps. Here\u2019s how it\u2019s useful in practice:<\/p>\n

It\u2019s event-driven, so you can automate the boring stuff:<\/strong> IssueOps lets you automate workflows directly from GitHub Issues and pull requests, turning everyday interactions\u2014from kicking off a CI\/CD pipeline and managing approvals to updating project boards\u2014into powerful triggers for GitHub Actions.<\/p>\n

It\u2019s customizable, so you can tailor workflows to your needs:<\/strong> No two teams work the same way, and IssueOps is flexible enough to adapt. Whether you\u2019re automating bug triage or triggering deployments, you can customize workflows based on event type and data provided.<\/p>\n

It\u2019s transparent, so you can keep a record:<\/strong> All actions taken on an issue are logged in its timeline, creating an easy-to-follow record of what happened and when.<\/p>\n

It\u2019s immutable, so you do an audit whenever you need:<\/strong> Because IssueOps uses GitHub Issues and pull requests as a source of truth, every action leaves a record. No more chasing approvals in Slack or manually triggering workflows: IssueOps keeps everything structured, automated, and auditable right inside GitHub.<\/p>\n

Our quickstart guide to IssueOps<\/p>\n

Step 1: Define your triggers<\/strong>
\nIdentify the actions that should kick off your workflows\u2014like opening an issue, adding a label, or merging a pull request. These events can serve as triggers for GitHub Actions.
\nStep 2: Configure GitHub Actions<\/strong><\/p>\n

Use GitHub Actions to define what happens when an event occurs. For example, if an issue is labeled deploy, you could trigger a deployment script. YAML never looked so good.<\/p>\n

Step 3: Test and iterate<\/strong><\/p>\n

Like any good automation, IssueOps workflows should be tested and refined. Start small, see what works, and expand from there.<\/p>\n

Let\u2019s go<\/strong>: Learn more in our repository<\/a>.<\/p>\n

Defining IssueOps workflows and how they\u2019re like finite-state machines<\/a><\/h2>\n

Most IssueOps workflows follow the same basic pattern:<\/p>\n

A user opens an issue and provides information about a request
\nThe issue is validated to ensure it contains the required information
\nThe issue is submitted for processing
\nApproval is requested from an authorized user or team
\nThe request is processed and the issue is closed<\/p>\n

Suppose you\u2019re an administrator of an organization and want to reduce the overhead of managing team members. In this instance, you could use IssueOps to build an automated membership request and approval process. Within a workflow like this, you\u2019d have several core steps:<\/p>\n

A user creates a request to be added to a team
\nThe request is validated
\nThe request is submitted for approval
\nAn administrator approves or denies this request
\nThe request is processed<\/p>\n

If approved<\/em>, the user is added to the team
\nIf denied<\/em>, the user is not added to the team <\/p>\n

The user is notified of the outcome<\/p>\n

When designing your own IssueOps workflows, it can be very helpful to think of them as a finite-state machine<\/a>: a model for how objects move through a series of states in response to external events. Depending on certain rules defined within the state machine, a number of different actions can take place in response to state changes. If this is a little too complex, you can also think of it like a flow chart.<\/p>\n

To apply this comparison to IssueOps, an issue is the object<\/em> that is processed by a state machine. It changes state<\/em> in response to events<\/em>. As the object changes state, certain actions<\/em> may be performed as part of a transition<\/em>, provided any required conditions (guards<\/em>) are met. Once an end state<\/em> is reached, the issue can be closed.<\/p>\n

This breaks down into a few key concepts:<\/p>\n

State<\/strong>: A point in an object\u2019s lifecycle that satisfies certain condition(s).
\nEvent<\/strong>: An external occurrence that triggers a state change.
\nTransition<\/strong>: A link between two states that, when traversed by an object, will cause certain action(s) to be performed.
\nAction<\/strong>: An atomic task that is performed when a transition is taken.
\nGuard<\/strong>: A condition that is evaluated when a trigger event occurs. A transition is taken only if all associated guard condition(s) are met.<\/p>\n

Here\u2019s a simple state diagram for the example I discussed above.<\/p>\n\n

Now, let\u2019s dive into the state machine in more detail!<\/p>\n

Key concepts behind state machines<\/a><\/h2>\n

The benefit of breaking your workflow down into these components is that you can look for edge cases, enforce conditions, and create a robust, reliable result.<\/p>\n

States<\/strong><\/a><\/h3>\n

Within a state machine, a state<\/em> defines the current status of an object. As the object transitions through the state machine, it will change states in response to external events. When building IssueOps workflows, common states for issues include opened, submitted, approved, denied, and closed.<\/p>\n

These should suffice as the core states to consider when building our workflows in our team membership example above.<\/p>\n

Events<\/strong><\/a><\/h3>\n

In a state machine, an event<\/em> can be any form of interaction with the object and its current state. When building your own IssueOps, you should consider events from both the user and GitHub points of view.<\/p>\n

In our team membership request example, there are several events that can trigger a change in state. The request can be created, submitted, approved, denied, or processed.<\/p>\n

In this example, a user interacting with an issue\u2014such as adding labels, commenting, or updating milestones\u2014can also change its state. In GitHub Actions, there are many events that can trigger your workflows (see events that trigger workflows<\/a>).<\/p>\n

Here are a few interactions, or events, that would affect our example IssueOps workflow when it comes to managing team members: <\/p>\n

\n

Request<\/strong>
\nEvent<\/strong>
\nState<\/strong><\/p>\n

Request is created
\nissues
\nopened<\/p>\n

Request is approved
\nissue_comment
\ncreated<\/p>\n

Request is denied
\nissue_comment
\ncreated<\/p>\n<\/div>\n

As you can see, the same GitHub workflow trigger can apply to multiple events in our state machine. Because of this, validation is key. Within your workflows, you should check both the type of event and the information provided by the user. In this case, we can conditionally trigger different workflow steps based on the content of the issue_comment event.<\/p>\n

jobs:
\n approve:
\n name: Process Approval
\n runs-on: ubuntu-latest<\/p>\n

if: ${{ startsWith(github.event.comment.body, ‘.approve’) }}<\/p>\n

# …<\/p>\n

deny:
\n name: Process Denial
\n runs-on: ubuntu-latest<\/p>\n

if: ${{ startsWith(github.event.comment.body, ‘.deny’) }}<\/p>\n

# …<\/p>\n

Transitions<\/a><\/h3>\n

A transition<\/em> is simply the change from one state to another. In our example, for instance, a transition occurs when someone opens an issue. When a request meets certain conditions, or guards, the change in state can take place. When the transition occurs, some actions or processing may take place, as well.<\/p>\n

With our example workflow, you can think of the transitions themselves as the lines connecting different nodes in the state diagram. Or the lines connecting boxes in a flow chart.<\/p>\n

Guards<\/a><\/h3>\n

Guards<\/em> are conditions that must be verified before an event can trigger a transition to a different state. In our case, we know the following guards must be in place:<\/p>\n

A request should not transition to an Approved state unless an administrator comments .approve on the issue.
\nA request should not transition to a Denied state unless an administrator comments .deny on the issue.<\/p>\n

What about after the request is approved and the user is added to the team? This is referred to as an unguarded transition<\/em>. There are no conditions that must be met, so the transition happens immediately!<\/p>\n

Actions<\/strong><\/a><\/h3>\n

Lastly, actions<\/em> are specific tasks that are performed during a transition. They may affect the object itself, but this is not a requirement in our state machine. In our example, the following actions may take place at different times:<\/p>\n

Administrators are notified that a request has been submitted
\nThe user is added to the requested team
\nThe user is notified of the outcome<\/p>\n

A real-world example: Building a team membership workflow with IssueOps<\/a><\/h2>\n

Now that all of the explanation is out of the way, let\u2019s dive into building our example! For reference, we\u2019ll focus on the GitHub Actions workflows involved in building this automation. There are some additional repository and permissions settings involved that are discussed in more detail in these IssueOps docs<\/a>.<\/p>\n

Step 1: Issue form template<\/a><\/h3>\n

GitHub issue forms<\/a> let you create standardized, formatted issues based on a set of form fields. Combined with the issue-ops\/parser<\/a> action, you can get reliable, machine-readable JSON from issue body Markdown. For our example, we are going to create a simple form that accepts a single input: the team where we want to add the user.<\/p>\n

name: Team Membership Request
\ndescription: Submit a new membership request
\ntitle: New Team Membership Request
\nlabels:
\n – team-membership
\nbody:
\n – type: input
\n id: team
\n attributes:
\n label: Team Name
\n description: The team name you would like to join
\n placeholder: my-team
\n validations:
\n required: true<\/p>\n

When issues are created using this form, they will be parsed into JSON, which can then be passed to the rest of the IssueOps workflow.<\/p>\n

{
\n “team”: “my-team”
\n}<\/p>\n

Step 2: Issue validation<\/a><\/h3>\n

With a machine-readable issue body, we can run additional validation checks to ensure the information provided follows any rules we might have in place. For example, we can\u2019t automatically add a user to a team if the team doesn\u2019t exist yet! That is where the issue-ops\/validator<\/a> action comes into play. Using an issue form template and a custom validation script, we can confirm the existence of the team ahead of time.<\/p>\n

module.exports = async (field) => {
\n const { Octokit } = require(‘@octokit\/rest’)
\n const core = require(‘@actions\/core’)<\/p>\n

const github = new Octokit({
\n auth: core.getInput(‘github-token’, { required: true })
\n })<\/p>\n

try {
\n \/\/ Check if the team exists
\n core.info(`Checking if team ‘${field}’ exists`)<\/p>\n

await github.rest.teams.getByName({
\n org: process.env.GITHUB_REPOSITORY_OWNER ?? ”,
\n team_slug: field
\n })<\/p>\n

core.info(`Team ‘${field}’ exists`)
\n return ‘success’
\n } catch (error) {
\n if (error.status === 404) {
\n \/\/ If the team does not exist, return an error message
\n core.error(`Team ‘${field}’ does not exist`)
\n return `Team ‘${field}’ does not exist`
\n } else {
\n \/\/ Otherwise, something else went wrong…
\n throw error
\n }
\n }
\n}<\/p>\n

When included in our IssueOps workflow, this adds any validation error(s) to the comment on the issue.<\/p>\n

Step 3: Issue workflows<\/a><\/h3>\n

The main \u201centrypoint\u201d of this workflow occurs when a user creates or edits their team membership request issue. This workflow should focus heavily on validating any user inputs! For example, what should happen if the user inputs a team that does not exist?<\/p>\n

In our state machine, this workflow is responsible for handling everything up to the opened<\/em> state. Any time an issue is created, edited, or updated, it will re-run validation to ensure the request is ready to be processed. In this case, an additional guard condition is introduced. Before the request can be submitted, the user must comment with .submit after validation has passed.<\/p>\n

name: Process Issue Open\/Edit<\/p>\n

on:
\n issues:
\n types:
\n – opened
\n – edited
\n – reopened<\/p>\n

permissions:
\n contents: read
\n id-token: write
\n issues: write<\/p>\n

jobs:
\n validate:
\n name: Validate Request
\n runs-on: ubuntu-latest<\/p>\n

# This job should only be run on issues with the `team-membership` label.
\n if: ${{ contains(github.event.issue.labels.*.name, ‘team-membership’) }}<\/p>\n

steps:
\n # This is required to ensure the issue form template and any validation
\n # scripts are included in the workspace.
\n – name: Checkout
\n id: checkout
\n uses: actions\/checkout@v4<\/p>\n

# Since this workflow includes custom validation scripts, we need to
\n # install Node.js and any dependencies.
\n – name: Setup Node.js
\n id: setup-node
\n uses: actions\/setup-node@v4<\/p>\n

# Install dependencies from `package.json`.
\n – name: Install Dependencies
\n id: install
\n run: npm install<\/p>\n

# GitHub App authentication is required if you want to interact with any
\n # resources outside the scope of the repository this workflow runs in.
\n – name: Get GitHub App Token
\n id: token
\n uses: actions\/create-github-app-token@v1
\n with:
\n app-id: ${{ vars.ISSUEOPS_APP_ID }}
\n private-key: ${{ secrets.ISSUEOPS_APP_PRIVATE_KEY }}
\n owner: ${{ github.repository_owner }}<\/p>\n

# Remove any labels and start fresh. This is important because the
\n # issue may have been closed and reopened.
\n – name: Remove Labels
\n id: remove-label
\n uses: issue-ops\/labeler@v2
\n with:
\n action: remove
\n github_token: ${{ steps.token.outputs.token }}
\n labels: |
\n validated
\n approved
\n denied
\n issue_number: ${{ github.event.issue.number }}
\n repository: ${{ github.repository }}<\/p>\n

# Parse the issue body into machine-readable JSON, so that it can be
\n # processed by the rest of the workflow.
\n – name: Parse Issue Body
\n id: parse
\n uses: issue-ops\/parser@v4
\n with:
\n body: ${{ github.event.issue.body }}
\n issue-form-template: team-membership.yml
\n workspace: ${{ github.workspace }}<\/p>\n

# Validate early and often! Validation should be run any time an issue is
\n # interacted with, to ensure that any changes to the issue body are valid.
\n – name: Validate Request
\n id: validate
\n uses: issue-ops\/validator@v3
\n with:
\n add-comment: true
\n github-token: ${{ steps.token.outputs.token }}
\n issue-form-template: team-membership.yml
\n issue-number: ${{ github.event.issue.number }}
\n parsed-issue-body: ${{ steps.parse.outputs.json }}
\n workspace: ${{ github.workspace }}<\/p>\n

# If validation passes, add the validated label to the issue.
\n – if: ${{ steps.validate.outputs.result == ‘success’ }}
\n name: Add Validated Label
\n id: add-label
\n uses: issue-ops\/labeler@v2
\n with:
\n action: add
\n github_token: ${{ steps.token.outputs.token }}
\n labels: |
\n validated
\n issue_number: ${{ github.event.issue.number }}
\n repository: ${{ github.repository }}<\/p>\n

# The `issue-ops\/validator` action will automatically notify the user that
\n # the request was validated. However, you can optionally add instruction
\n # on what to do next.
\n – if: ${{ steps.validate.outputs.result == ‘success’ }}
\n name: Notify User (Success)
\n id: notify-success
\n uses: peter-evans\/create-or-update-comment@v4
\n with:
\n issue-number: ${{ github.event.issue.number }}
\n body: |
\n Hello! Your request has been validated successfully!<\/p>\n

Please comment with `.submit` to submit this request.<\/p>\n

Step 4: Issue comment workflows<\/a><\/h3>\n

Once the issue is created, any further processing is triggered using issue comments\u2014and this can be done with one workflow. However, to make things a bit easier to follow, we\u2019ll break this into a few separate workflows.<\/p>\n

Submit workflow<\/a><\/h4>\n

The first workflow handles the user submitting the request. The main task it performs is validating the issue body against the form template to ensure it hasn\u2019t been modified.<\/p>\n

name: Process Submit Comment<\/p>\n

on:
\n issue_comment:
\n types:
\n – created<\/p>\n

permissions:
\n contents: read
\n id-token: write
\n issues: write<\/p>\n

jobs:
\n submit:
\n name: Submit Request
\n runs-on: ubuntu-latest<\/p>\n

# This job should only be run when the following conditions are true:
\n #
\n # – A user comments `.submit` on the issue.
\n # – The issue has the `team-membership` label.
\n # – The issue has the `validated` label.
\n # – The issue does not have the `approved` or `denied` labels.
\n # – The issue is open.
\n if: |
\n startsWith(github.event.comment.body, ‘.submit’) &&
\n contains(github.event.issue.labels.*.name, ‘team-membership’) == true &&
\n contains(github.event.issue.labels.*.name, ‘approved’) == false &&
\n contains(github.event.issue.labels.*.name, ‘denied’) == false &&
\n github.event.issue.state == ‘open’<\/p>\n

steps:
\n # First, we are going to re-run validation. This is important because
\n # the issue body may have changed since the last time it was validated.<\/p>\n

# This is required to ensure the issue form template and any validation
\n # scripts are included in the workspace.
\n – name: Checkout
\n id: checkout
\n uses: actions\/checkout@v4<\/p>\n

# Since this workflow includes custom validation scripts, we need to
\n # install Node.js and any dependencies.
\n – name: Setup Node.js
\n id: setup-node
\n uses: actions\/setup-node@v4<\/p>\n

# Install dependencies from `package.json`.
\n – name: Install Dependencies
\n id: install
\n run: npm install<\/p>\n

# GitHub App authentication is required if you want to interact with any
\n # resources outside the scope of the repository this workflow runs in.
\n – name: Get GitHub App Token
\n id: token
\n uses: actions\/create-github-app-token@v1
\n with:
\n app-id: ${{ vars.ISSUEOPS_APP_ID }}
\n private-key: ${{ secrets.ISSUEOPS_APP_PRIVATE_KEY }}
\n owner: ${{ github.repository_owner }}<\/p>\n

# Remove the validated label. This will be re-added if validation passes.
\n – name: Remove Validated Label
\n id: remove-label
\n uses: issue-ops\/labeler@v2
\n with:
\n action: remove
\n github_token: ${{ steps.token.outputs.token }}
\n labels: |
\n validated
\n issue_number: ${{ github.event.issue.number }}
\n repository: ${{ github.repository }}<\/p>\n

# Parse the issue body into machine-readable JSON, so that it can be
\n # processed by the rest of the workflow.
\n – name: Parse Issue Body
\n id: parse
\n uses: issue-ops\/parser@v4
\n with:
\n body: ${{ github.event.issue.body }}
\n issue-form-template: team-membership.yml
\n workspace: ${{ github.workspace }}<\/p>\n

# Validate early and often! Validation should be run any time an issue is
\n # interacted with, to ensure that any changes to the issue body are valid.
\n – name: Validate Request
\n id: validate
\n uses: issue-ops\/validator@v3
\n with:
\n add-comment: false # Don’t add another validation comment.
\n github-token: ${{ steps.token.outputs.token }}
\n issue-form-template: team-membership.yml
\n issue-number: ${{ github.event.issue.number }}
\n parsed-issue-body: ${{ steps.parse.outputs.json }}
\n workspace: ${{ github.workspace }}<\/p>\n

# If validation passed, add the validated and submitted labels to the issue.
\n – if: ${{ steps.validate.outputs.result == ‘success’ }}
\n name: Add Validated Label
\n id: add-label
\n uses: issue-ops\/labeler@v2
\n with:
\n action: add
\n github_token: ${{ steps.token.outputs.token }}
\n labels: |
\n validated
\n submitted
\n issue_number: ${{ github.event.issue.number }}
\n repository: ${{ github.repository }}<\/p>\n

# If validation succeeded, alert the administrator team so they can
\n # approve or deny the request.
\n – if: ${{ steps.validate.outputs.result == ‘success’ }}
\n name: Notify Admin (Success)
\n id: notify-success
\n uses: peter-evans\/create-or-update-comment@v4
\n with:
\n issue-number: ${{ github.event.issue.number }}
\n body: |
\n \ud83d\udc4b @issue-ops\/admins! The request has been validated and is
\n ready for your review. Please comment with `.approve` or `.deny`
\n to approve or deny this request.<\/p>\n

Deny workflow<\/a><\/h4>\n

If the request is denied, the user should be notified and the issue should close.<\/p>\n

name: Process Denial Comment<\/p>\n

on:
\n issue_comment:
\n types:
\n – created<\/p>\n

permissions:
\n contents: read
\n id-token: write
\n issues: write<\/p>\n

jobs:
\n submit:
\n name: Deny Request
\n runs-on: ubuntu-latest<\/p>\n

# This job should only be run when the following conditions are true:
\n #
\n # – A user comments `.deny` on the issue.
\n # – The issue has the `team-membership` label.
\n # – The issue has the `validated` label.
\n # – The issue has the `submitted` label.
\n # – The issue does not have the `approved` or `denied` labels.
\n # – The issue is open.
\n if: |
\n startsWith(github.event.comment.body, ‘.deny’) &&
\n contains(github.event.issue.labels.*.name, ‘team-membership’) == true &&
\n contains(github.event.issue.labels.*.name, ‘submitted’) == true &&
\n contains(github.event.issue.labels.*.name, ‘validated’) == true &&
\n contains(github.event.issue.labels.*.name, ‘approved’) == false &&
\n contains(github.event.issue.labels.*.name, ‘denied’) == false &&
\n github.event.issue.state == ‘open’<\/p>\n

steps:
\n # This time, we do not need to re-run validation because the request is
\n # being denied. It can just be closed.<\/p>\n

# However, we do need to confirm that the user who commented `.deny` is
\n # a member of the administrator team.
\n # GitHub App authentication is required if you want to interact with any
\n # resources outside the scope of the repository this workflow runs in.
\n – name: Get GitHub App Token
\n id: token
\n uses: actions\/create-github-app-token@v1
\n with:
\n app-id: ${{ vars.ISSUEOPS_APP_ID }}
\n private-key: ${{ secrets.ISSUEOPS_APP_PRIVATE_KEY }}
\n owner: ${{ github.repository_owner }}<\/p>\n

# Check if the user who commented `.deny` is a member of the
\n # administrator team.
\n – name: Check Admin Membership
\n id: check-admin
\n uses: actions\/github-script@v7
\n with:
\n github-token: ${{ steps.token.outputs.token }}
\n script: |
\n try {
\n await github.rest.teams.getMembershipForUserInOrg({
\n org: context.repo.owner,
\n team_slug: ‘admins’,
\n username: context.actor,
\n })
\n core.setOutput(‘member’, ‘true’)
\n } catch (error) {
\n if (error.status === 404) {
\n core.setOutput(‘member’, ‘false’)
\n }
\n throw error
\n }<\/p>\n

# If the user is not a member of the administrator team, exit the
\n # workflow.
\n – if: ${{ steps.check-admin.outputs.member == ‘false’ }}
\n name: Exit
\n run: exit 0<\/p>\n

# If the user is a member of the administrator team, add the denied label.
\n – name: Add Denied Label
\n id: add-label
\n uses: issue-ops\/labeler@v2
\n with:
\n action: add
\n github_token: ${{ steps.token.outputs.token }}
\n labels: |
\n denied
\n issue_number: ${{ github.event.issue.number }}
\n repository: ${{ github.repository }}<\/p>\n

# Notify the user that the request was denied.
\n – name: Notify User
\n id: notify
\n uses: peter-evans\/create-or-update-comment@v4
\n with:
\n issue-number: ${{ github.event.issue.number }}
\n body: |
\n This request has been denied and will be closed.<\/p>\n

# Close the issue as not planned.
\n – name: Close Issue
\n id: close
\n uses: actions\/github-script@v7
\n with:
\n script: |
\n await github.rest.issues.update({
\n issue_number: ${{ github.event.issue.number }},
\n owner: context.repo.owner,
\n repo: context.repo.repo,
\n state: ‘closed’,
\n state_reason: ‘not_planned’
\n })<\/p>\n

Approve workflow<\/a><\/h4>\n

Finally, we need to handle request approval. In this case, we need to add the user to the team, notify them, and close the issue.<\/p>\n

name: Process Approval Comment<\/p>\n

on:
\n issue_comment:
\n types:
\n – created<\/p>\n

permissions:
\n contents: read
\n id-token: write
\n issues: write<\/p>\n

jobs:
\n submit:
\n name: Approve Request
\n runs-on: ubuntu-latest<\/p>\n

# This job should only be run when the following conditions are true:
\n #
\n # – A user comments `.approve` on the issue.
\n # – The issue has the `team-membership` label.
\n # – The issue has the `validated` label.
\n # – The issue has the `submitted` label.
\n # – The issue does not have the `approved` or `denied` labels.
\n # – The issue is open.
\n if: |
\n startsWith(github.event.comment.body, ‘.approve’) &&
\n contains(github.event.issue.labels.*.name, ‘team-membership’) == true &&
\n contains(github.event.issue.labels.*.name, ‘submitted’) == true &&
\n contains(github.event.issue.labels.*.name, ‘validated’) == true &&
\n contains(github.event.issue.labels.*.name, ‘approved’) == false &&
\n contains(github.event.issue.labels.*.name, ‘denied’) == false &&
\n github.event.issue.state == ‘open’<\/p>\n

steps:
\n # This time, we do not need to re-run validation because the request is
\n # being approved. It can just be processed.<\/p>\n

# This is required to ensure the issue form template is included in the
\n # workspace.
\n – name: Checkout
\n id: checkout
\n uses: actions\/checkout@v4<\/p>\n

# We do need to confirm that the user who commented `.approve` is a member
\n # of the administrator team. GitHub App authentication is required if you
\n # want to interact with any resources outside the scope of the repository
\n # this workflow runs in.
\n – name: Get GitHub App Token
\n id: token
\n uses: actions\/create-github-app-token@v1
\n with:
\n app-id: ${{ vars.ISSUEOPS_APP_ID }}
\n private-key: ${{ secrets.ISSUEOPS_APP_PRIVATE_KEY }}
\n owner: ${{ github.repository_owner }}<\/p>\n

# Check if the user who commented `.approve` is a member of the
\n # administrator team.
\n – name: Check Admin Membership
\n id: check-admin
\n uses: actions\/github-script@v7
\n with:
\n github-token: ${{ steps.token.outputs.token }}
\n script: |
\n try {
\n await github.rest.teams.getMembershipForUserInOrg({
\n org: context.repo.owner,
\n team_slug: ‘admins’,
\n username: context.actor,
\n })
\n core.setOutput(‘member’, ‘true’)
\n } catch (error) {
\n if (error.status === 404) {
\n core.setOutput(‘member’, ‘false’)
\n }
\n throw error
\n }<\/p>\n

# If the user is not a member of the administrator team, exit the
\n # workflow.
\n – if: ${{ steps.check-admin.outputs.member == ‘false’ }}
\n name: Exit
\n run: exit 0<\/p>\n

# Parse the issue body into machine-readable JSON, so that it can be
\n # processed by the rest of the workflow.
\n – name: Parse Issue body
\n id: parse
\n uses: issue-ops\/parser@v4
\n with:
\n body: ${{ github.event.issue.body }}
\n issue-form-template: team-membership.yml
\n workspace: ${{ github.workspace }}<\/p>\n

– name: Add to Team
\n id: add
\n uses: actions\/github-script@v7
\n with:
\n github-token: ${{ steps.token.outputs.token }}
\n script: |
\n const parsedIssue = JSON.parse(‘${{ steps.parse.outputs.json }}’)<\/p>\n

await github.rest.teams.addOrUpdateMembershipForUserInOrg({
\n org: context.repo.owner,
\n team_slug: parsedIssue.team,
\n username: ‘${{ github.event.issue.user.login }}’,
\n role: ‘member’
\n })<\/p>\n

– name: Notify User
\n id: notify
\n uses: peter-evans\/create-or-update-comment@v4
\n with:
\n issue-number: ${{ github.event.issue.number }}
\n body: |
\n This request has been processed successfully!<\/p>\n

– name: Close Issue
\n id: close
\n uses: actions\/github-script@v7
\n with:
\n script: |
\n await github.rest.issues.update({
\n issue_number: ${{ github.event.issue.number }},
\n owner: context.repo.owner,
\n repo: context.repo.repo,
\n state: ‘closed’,
\n state_reason: ‘completed’
\n })<\/p>\n

Take this with you<\/a><\/h2>\n

And there you have it! With a handful of standardized workflows, you have an end-to-end, issue-driven process in place to manage team membership. This can be extended as far as you want, including support for removing users, auditing access, and more. With IssueOps, the sky is the limit!<\/p>\n

Here\u2019s the best thing about IssueOps: It brings another level of automation to a surface I\u2019m constantly using\u2014and that\u2019s GitHub. By using issues and pull requests as control centers for workflows, teams can reduce friction, improve efficiency, and keep everything transparent. Whether you want to automate deployments, approvals, or bug triage, IssueOps makes it all possible, without ever leaving your repo.<\/p>\n

For more information and examples, check out the open source IssueOps documentation repository<\/a>, and if you want a deeper dive, you can head over to the open source IssueOps documentation<\/a>.<\/p>\n

In my experience, it\u2019s always best to start small and experiment with what works best for you. With just a bit of time, you\u2019ll see your workflows get smoother with every commit (I know I have). Happy coding! \u2728<\/p>\n

The post IssueOps: Automate CI\/CD (and more!) with GitHub Issues and Actions<\/a> appeared first on The GitHub Blog<\/a>.<\/p>","protected":false},"excerpt":{"rendered":"

Software development is filled with repetitive tasks\u2014managing issues, handling approvals, triggering CI\/CD workflows, and more. But what if you could […]<\/p>\n","protected":false},"author":0,"featured_media":0,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[8],"tags":[],"class_list":["post-1846","post","type-post","status-publish","format-standard","hentry","category-github-engineering"],"_links":{"self":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/1846","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/comments?post=1846"}],"version-history":[{"count":0,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/posts\/1846\/revisions"}],"wp:attachment":[{"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/media?parent=1846"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/categories?post=1846"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rssfeedtelegrambot.bnaya.co.il\/index.php\/wp-json\/wp\/v2\/tags?post=1846"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}