Redeploy
Redeploying builds a deployment's source again, as a new deployment. Use it to apply changed environment variables or build settings, or to retry a build that failed for a passing reason, like a registry hiccup.
From the CLI
Deploy again from the same directory:
The CLI uploads your files as they are now. To rebuild exactly what was deployed before, check out that commit first.
From the dashboard
Open the project in the dashboard, then the menu of a deployment in its recent deployments, and choose Redeploy. It's available for deployments made from a GitHub repository: Hiraiship builds the same commit again, with the project's current build settings. Commits pushed to the branch since then aren't included: to build the branch's latest commit, deploy the branch again.
A deployment from a GitHub repository records the commit it built, with its message and author. The branch is resolved to its commit when the deployment is created, so the build is the commit you saw, even if someone pushes while it runs.
A deployment made with the CLI can't be redeployed from the dashboard, since Hiraiship doesn't keep the files you uploaded. Deploy again from your machine.
Redeploy or roll back?
| Redeploy | Rollback | |
|---|---|---|
| Builds again | Yes | No |
| Takes | A build's time | Seconds |
| Uses current build settings | Yes | No, the deployment's own build |
| Uses current variables | Yes | Yes |
To go back to a version that worked, roll back: it's faster and can't fail on a build.