Roll back a deployment
Re-run the newest earlier successful deployment to the same deployment environment, and what Prodgator exposes to automation.
Availability
Rollback
Roll back from the Gates page's History tab, or a gate's own History. A deployment there has a button that names what it deploys again, for example Roll back to v1.4.0 (abc1234): the newest earlier successful deployment to the same deployment environment (the same repository, environment and workflow). A deployment from another workflow to the same environment is never re-run. A deployment with no earlier success has no Rollback button.
The confirmation shows the environment, the repository, the target's commit, when it was first deployed, the deployment it replaces, and how the provider runs it. If the target changed after the page loaded (a newer deployment finished meanwhile), nothing runs and Prodgator asks you to reload.
A run's expanded row on Pipelines has no Rollback. Its jobs and deployments link to the deployment environment's History, where Rollback is. To run one job of that run again, use Re-run on its row.
The rolled back release shows as Rolled Back in history.
GitHub Actions
Prodgator re-runs that deployment's workflow run.
GitLab CI/CD
Prodgator does what GitLab's own Rollback environment does: it runs the earlier deployment's deploy job again. GitLab records who ran a job, so the job runs as your own GitLab account. Link it first in your profile under Linked accounts. Your GitLab account must be allowed to deploy to the environment; a protected environment that requires approval asks for it again.
Azure Pipelines
Prodgator runs the earlier deployment's stage again on its build, the way Retry stage does in Azure DevOps. Azure DevOps records who retried a stage, so Prodgator does it as your own linked Azure DevOps account. Link it first in your profile under Linked accounts. The environment's approvals and checks apply again, the Prodgator gate included.
Bitbucket Pipelines
Rollback is not available. Bitbucket has no API to run a deployment step again. Use Redeploy on the earlier deployment in Bitbucket's Deployments page instead.
From automation
Gates are not exposed to API keys. You can approve or reject deployments with an API key that has the scope. See the Public REST API.
The web app's own routes for gates are and (see App API). They take a signed-in user's access token, not an API key.