How to Automate Your CI/CD Pipeline with Programmable Issue Management

A broken build in your CI/CD pipeline is a critical event. It stops features from shipping, blocks other developers, and requires immediate attention. But how is that failure communicated? Too often, it’s a transient notification lost in a noisy Slack channel or a generic email that's easily ignored. The developer who broke the build might not even see it for hours. Meanwhile, the pipeline stays red.

What if you could treat that build failure like any other critical bug? What if you could automatically create a high-priority, fully-contextualized task and assign it to the right person, all within seconds of the failure?

This is the power of programmable issue management. By embedding issue tracking directly into your build and deploy process, you can move from noisy notifications to actionable, trackable work. This tutorial will show you how to use issues.do, an API for modern issue tracking, to automatically fail a build, create a high-priority issue, and assign it to the right team.

Why Your CI/CD Pipeline Needs a Task Management API

Traditional issue trackers are GUIs. They are disconnected from the automated systems where work actually happens and breaks. An API-first approach, like the one provided by issues.do, fundamentally changes this relationship.

By managing bugs, tasks, and incidents as code, you gain several key advantages:

• Immediate Triage and Accountability: When a build fails, an issue is instantly created and assigned. There's no ambiguity about who is responsible for the fix. The problem is officially "on the books" and won't get lost.
• Rich, Automated Context: The automated script can package up all the necessary context—the commit hash, a link to the build logs, the stage that failed—and include it in the issue description. No more manual copy-pasting for the developer.
• Reduced MTTR (Mean Time to Resolution): By eliminating the manual steps of discovery, reporting, and assignment, your team can start working on the fix faster. This keeps your development velocity high and your pipelines green.
• A Single Source of Truth: Instead of scattering information across Git, CI logs, and Slack, the issue becomes the central hub for the problem, from discovery to resolution.

The Old Way vs. The issues.do Way

Let's contrast the manual process with an automated one.

The Old Way:

1. The test stage of your CI pipeline fails.
2. A generic "Build Failed" notification is sent to #dev-alerts.
3. It gets buried under other messages. 30 minutes later, a developer notices the red pipeline.
4. They open the build logs to investigate.
5. They manually create a ticket in a separate tool.
6. They copy the commit hash and paste a link to the logs.
7. They manually assign the ticket.

The New Way with issues.do:

1. The test stage of your CI pipeline fails.
2. An on: failure step immediately calls the issues.do API.
3. A high-priority issue is instantly created with the title "CI Build Failed: main branch," assigned to the on-call team, and populated with the commit hash and a direct link to the logs.

The automated workflow takes seconds and requires zero human intervention to get the ball rolling.

Tutorial: Automating Issue Creation on Build Failure

Let's build a practical example using GitHub Actions. The same principles apply to GitLab CI, Jenkins, CircleCI, or any other modern CI/CD system.

Prerequisites

• An issues.do account.
• An API key generated from your issues.do settings. We'll store this as a secret in our repository.
• A repository with a basic CI/CD pipeline.

Step 1: Add Your API Key as a Repository Secret

In your GitHub repository, navigate to Settings > Secrets and variables > Actions. Click New repository secret and create a secret named ISSUES_DO_API_KEY with the value of your API key.

Step 2: Define the Build Job

Here is a simple workflow that runs tests. We'll add a step that intentionally fails for this demonstration.

# .github/workflows/ci.yml

name: CI Pipeline

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Run unit tests
        run: |
          echo "Running application tests..."
          # This command will fail, triggering our issue creation step
          exit 1

Step 3: Add the Automated Issue Creation Step

Now for the magic. We'll add a new step to this job that only runs if a preceding step has failed. This step will use curl to make a POST request to the issues.do API.

# .github/workflows/ci.yml

name: CI Pipeline

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Run unit tests
        id: tests
        run: |
          echo "Running application tests..."
          exit 1

      - name: Create Issue on Failure
        # This step only runs if the 'tests' step failed
        if: failure() && steps.tests.outcome == 'failure'
        run: |
          curl -X POST https://api.issues.do/v1/issues \
          -H "Authorization: Bearer ${{ secrets.ISSUES_DO_API_KEY }}" \
          -H "Content-Type: application/json" \
          -d '{
            "title": "CI Build Failed on branch ${{ github.ref_name }}",
            "description": "The `Run unit tests` step failed for commit `${{ github.sha }}`. \n\n[View Build Logs](${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }})",
            "priority": "High",
            "assignee": "dev-team@example.com",
            "labels": ["bug", "ci-failure", "automated"]
          }'

Let's break down the Create Issue on Failure step:

• if: failure() && steps.tests.outcome == 'failure': This condition ensures the step only executes when the build job has failed, specifically because the step with id: tests failed.
• curl -X POST ...: This is the command that calls the issues.do API endpoint to create a new issue.
• -H "Authorization: Bearer ${{ secrets.ISSUES_DO_API_KEY }}": This securely passes your API key from GitHub Secrets into the request header.
• -d '{...}': This is the JSON payload containing the issue details.
  • title: We use a dynamic title with the branch name (${{ github.ref_name }}).
  • description: We craft a helpful description that includes the exact commit hash (${{ github.sha }}) and a clickable link directly to the failed GitHub Actions run.
  • priority, assignee, labels: We automatically set the priority, assign it to a team email alias, and add relevant labels for easy filtering and reporting.

Now, when this workflow runs and the test step fails, a perfectly formatted, high-priority issue will be waiting in your issues.do project dashboard.

Go Beyond Failures: Manage Your Entire Workflow

Automating incident response for build failures is just the beginning. With a powerful task management API like issues.do, you can orchestrate your entire development lifecycle:

• Link Commits to Issues: Automatically append commit messages to related issues.
• Automate QA Tasks: When a feature branch is deployed to a staging environment, create a "QA Review" task and assign it to the QA team.
• Track Deployments: Create an issue every time a new version is deployed to production to maintain a clear audit log.
• Integrate with Monitoring: Trigger new issues from alerts in your monitoring tools like Prometheus or Datadog.

By treating your operational tasks as code, you create a development process that is more resilient, transparent, and efficient.

Ready to streamline your development lifecycle? Get started with issues.do today and integrate powerful, programmable issue tracking directly into your workflows.