Run details

Open a run from the Pipelines list to see its jobs, deployments and reports, and to cancel or re-run it.

Expanding a rowCopy Anchor Link

Click a row (or its arrow) to expand it in place. You can expand several rows at once. The expanded row shows:

• Open run, Open in the provider, and Artifacts for GitHub Actions runs.
• The release name, the full commit message, and how long the run was queued before its first job started.
• On a phone, also the trigger, repository, branch, actor, environments and job progress (the table shows these as columns).
• Summary: the run's reports, when it has any.
• The run's jobs with their status, duration and start time, which update live while the run is going.

Deployments on their jobsCopy Anchor Link

Each deployment shows on the row of the job that made it: the deployment environment's name, the deployment's status, its gates, a View link that opens the environment's URL in a new tab (when the provider sends one) and the deployment environment's History, where you can roll back to a named earlier deployment. On a phone, the deployment shows under its job.

Every expanded run's job table has the same columns: Job, Status, Duration, Started, Environment, Deployment, Prodgator, External gates, Link and the actions, whether or not the run deployed anything. A job's name links to that job on GitHub Actions, GitLab or Bitbucket, or to the Jenkins build, when Prodgator knows its URL. When the table is short of room, the deployment status, the link and the actions show as icons (hover one for its name); in a narrower space, such as a tablet, the jobs are listed as on a phone.

The Prodgator column shows Prodgator's gate with the same badges as the Pull requests page: Waiting, Passing once approved, Failing when rejected, Overridden when an admin overrode the release policy, Observe only when only observe-mode policies looked at it, Bypassed when someone deployed without Prodgator's approval, and Not answered when the deployment ended before anyone answered. Select the badge to open the gate's details: the release risk summary, the release policies and each approval or rejection with who gave it, when and their note. The details are read-only. The column says Not gated when Prodgator's gate did not hold the deployment. On a phone, the gate shows as an icon.

The External gates column shows, as small icons, the protections the CI platform itself put on the deployment environment, as far as its events tell Prodgator: GitHub required reviewers (with how many users and teams) and custom deployment protection rules, and GitLab protected environment approvals. Each icon is amber while it waits, green once approved and red when rejected, and opens the run on the provider. Wait timers, branch and tag policies, GitLab allowed deployers and Bitbucket deployment permissions are not in those events, so they are not shown.

Prodgator links a deployment to its job by the provider's job id: the GitHub Actions job named in the deployment status, the GitLab job of the deployment, or the Bitbucket step that ran it. GitHub sends the environment URL as the deployment's environment_url and GitLab as the environment's external URL; Bitbucket sends none. Deployments recorded before job ids were kept match a job only when exactly one job's name contains the environment's name.

A deployment that matches no job on the screen (for example, one from another attempt) is listed under Deployments instead.

For GitHub Actions and Azure Pipelines runs, operator and above also get Re-run failed jobs and Cancel run. For GitHub Actions and GitLab runs, each finished job has a Re-run button (see Re-run a job).

A deployment environment's name opens it on the Gates page:

• If the deployment environment is linked to a gate, its name opens that gate's page, which shows its pending approvals, active deployments and history.
• Otherwise it opens the deployment environment's entry on the Gates list, with the gates it belongs to and links to its Awaiting approval and History. On the Team plan (no Gates list) it opens that deployment environment's History.

Re-run a jobCopy Anchor Link

Re-run on a job row runs that job again, like Re-run job in GitHub or Retry in GitLab. It is on jobs that passed, failed or were cancelled, not on jobs that are running or were skipped, and only once the run has finished. It needs operator or above (the Re-run runs permission). A dialog names the job before anything runs. On a narrow table or a phone the button is a re-run icon; its label names the job.

• GitHub Actions: Prodgator asks GitHub to re-run the job with the Prodgator GitHub App. GitHub adds an attempt to the run. Environment protection rules apply again.
• GitLab CI/CD: Prodgator retries the job with your organization's GitLab connection, not your own linked account. GitLab creates a new job. If the job is manual, the new job waits until someone starts it in GitLab; Prodgator does not start it and says so.
• Bitbucket Pipelines: not available. Bitbucket has no API to run one step again; use Rerun failed steps in Bitbucket.
• Azure Pipelines: not available for one job. Azure Pipelines retries a whole stage, so use Re-run failed jobs on the run, or retry the stage in Azure DevOps.
• Jenkins: not available.

Each re-run is recorded in the audit log with the Prodgator user who asked for it.

Re-run runs this job only. It never rolls back a deployment: to deploy an earlier release again, use Rollback in the deployment environment's History.

Re-runs and attemptsCopy Anchor Link

A re-run keeps the run and adds an attempt. The jobs show one attempt at a time, the latest by default, and the row's status is the latest attempt's. When a run has more than one attempt, an Attempt 2 of 2 menu above the jobs (in the expanded row and on the run's page) switches to another attempt, with its status, start time and duration. Jobs are re-run only from the latest attempt.

• GitHub Actions: after Re-run failed jobs, the jobs that passed before are listed in the new attempt too, marked From attempt 1, as GitHub lists them.
• Bitbucket Pipelines: steps run again with Rerun failed steps belong to the pipeline's next run, when Bitbucket reports it on the step.
• GitLab CI: GitLab has no pipeline attempts. A retried job shows its latest try; Show retried jobs lists the earlier tries.

GitHub Actions runs re-run before Prodgator recorded attempts get them from GitHub the first time their jobs are shown. Other older runs show each job's latest try.

Run detailsCopy Anchor Link

Click the workflow name (or View details in the row's menu) to open the run's page. It shows the run's jobs with their durations, the commit, branch and author, the failure category if the run failed, and a link to the run on the provider.

For GitHub Actions and Azure Pipelines runs, operator and above can cancel a running run or re-run failed jobs. For GitHub Actions and GitLab runs they can also re-run one finished job. The run updates as the provider reports progress.

Row actionsCopy Anchor Link

The ... menu on a table row offers:

• View details: opens the run's page.
• View logs: opens the run on the provider.
• Pin to top or Unpin (see Find runs).
• Re-run failed jobs and Cancel run: GitHub Actions and Azure Pipelines runs, for operator and above.
• Approve deployment... and Reject deployment...: see Approve from the Pipelines list.

The ... menu above the list can refresh the list, export the runs on screen (pinned runs plus the current page) as CSV, and clear filters.

Live updatesCopy Anchor Link

The app keeps a WebSocket connection open while you use it. When a provider reports a change, Prodgator stores it and pushes it to every open browser in your organization, usually within a few seconds. No refresh is needed.

If the connection drops, the app reconnects with increasing delays and sends a heartbeat every 30 seconds to keep the connection open through proxies.