CI Manager: failed runs in GitHub Actions, GitLab CI and Jenkins

CI Manager investigates failed CI runs in GitHub Actions, GitLab CI, Jenkins, CircleCI and Azure DevOps, retries only transient failures and unblocks stuck queues.

REQUEST DEMO

READ THE DOCS

2501's CI Manager specialty investigates failed runs in GitHub Actions, GitLab CI, Jenkins, CircleCI and Azure DevOps, retries the ones that failed for a transient reason, and unblocks stuck queues. Real failures go to their owner, and it acts only as far as you allow.

In a notification, a download that timed out and will work on the next run looks exactly like a test someone broke. Rerunning everything wastes build time and hides the real failures.

What 2501 does

The CI specialty takes these requests from your ticketing system. It separates transient failures, such as a network timeout or a build machine that dropped out, from real ones: a failing test or build, an expired password or key, a deployment that failed its checks. A transient failure gets one retry, and the agent waits for the result before closing the ticket. A real failure goes with the evidence to the developer who made the change, the platform team or the service owner. For a stuck queue, it finds out whether build machines are offline, at capacity or unable to take the job.

Scope map of 2501's CI Manager: it investigates failed build, test and deploy runs, retries transient failures, reruns a deployment only once the target environment is confirmed and unblocks stuck queues by finding why build machines cannot take the job; real failures go with the evidence to whoever owns the fix, shared production build machines are never restarted on its own, and pipeline definitions and stored credentials are never edited.

You stay in control

You choose the level, per specialty: investigate only, act after a person confirms, or act on its own within your rules.
Deploys are special: a deployment job is never rerun before the target environment's state is confirmed.
Pipelines and credentials stay yours: it never edits pipeline definitions or stored credentials, and never restarts shared production build machines on its own.
On-prem, cloud or hybrid: 2501 runs wherever you do. On-prem, no data leaves your network.

Frequently asked

Which CI systems does it work with? GitHub Actions, GitLab CI, Jenkins, CircleCI and Azure DevOps.

Will it keep rerunning a test that fails at random? No. It retries a failure once at most, and a test that fails again goes to its author with the evidence.

Problems it handles

Each page is one kind of ticket, and how this specialty handles it within the limits you set.

A failed CI run is classified by 2501 as transient or real: a transient failure is retried once, and a real one goes with the evidence to the author, the platform team or the service owner

Problem

Failed CI run: flaky or real?

Rerunning a failed pipeline until it passes wastes build time and hides real breaks. How 2501 retries transient CI failures once and sends real ones to their owner.

See how it is handled

CI Manager: failed runs in GitHub Actions, GitLab CI and Jenkins

What 2501 does

You stay in control

Frequently asked

Related

Problems it handles

SEE IT ON YOUR OWN INFRASTRUCTURE