On Failure & Rollback
You can define what will happen if an action block fails, and if a rollback is needed, how the rollback will take place. This will ensure that your devices are left in a stable and known state.
Last updated
You can define what will happen if an action block fails, and if a rollback is needed, how the rollback will take place. This will ensure that your devices are left in a stable and known state.
Last updated
If a failure occurs during a software update, it is important to return your device to a stable and known state. When an action block fails, the default behavior of JFrog Connect is to run a general rollback. However, you can have more control over the process by configuring On Failure instructions in each action block in the flow and defining the rollback actions to be taken per action block.
For each action block, you can decide what kind of rollback is triggered (if any), and trigger actions such as a command or a custom script to run. When an update deployment ends, either successfully or due to a failure in the update flow, the outcome will be that your device is left in a stable state and you will have full knowledge of that state.
The purpose of the general rollback is to ensure that your application will always be able to return to a stable and running state. A general rollback is a rollback of all the action blocks that have been wholly or partially completed so far. This includes deleting any files that have been delivered, returning the directory structure to its previous state, and undoing any commands and scripts that have run so far. After a general rollback, your previously running versions will be running again.
Running the general rollback is the default On-Failure action marked in all of the action blocks. Although you can opt not to run a general rollback, we highly recommend including general rollback in each update flow.
If you chose Run General Rollback in any of your action blocks, you need to enable and configure the Rollback action block. This includes entering the command or script that will perform the rollback.
In the Create Update Flow page, click Rollback.
Mark Enable General Update Rollback.
Choose to run either a command or a script that will perform the rollback. If you choose Command, include the values for all required parameters. If you choose Script, you will need to prepare the script in advance.
Save your rollback configuration.
In the Configure Action popup, click On Failure.
The On Failure policy determines which action(s) to be taken if the action block fails. You can choose from the following.
Continue Update Flow: The update flow will continue to the next action block as if the action block succeeded (i.e., the error is ignored). If there are no more action blocks, the software update will go to completion. In the deployment output, you will see that the action block failed and the error that caused the failure.
Run General Rollback: When this is marked, the general rollback will run. (This is marked by default, but you can unmark it.) You can choose to run both the general rollback and an additional “Do Action” which is defined specifically per action block. The general rollback will run only after all the action-block specific rollback instructions have run.
Tip: If you mark Run General Rollback, you must also enable general rollback in the Rollback action block.
When you mark Execute Customized Action, a rollback action (e.g., a command or a script) specific to that action block will run. You can choose to run only a customized action to roll back the action block, or run it in addition to the general rollback.
The action is triggered as described below.
Trigger when:
Whole update fails: If this action block or a subsequent action block fails, then the rollback action specified will be triggered. If a subsequent action fails and has Continue Update Flow defined, then the action will not be triggered. (This option requires Connect Agent version 6.0 or later.)
Only this action fails: The rollback action will run only if the current action block fails.
When there are several action blocks in an update flow, the rollback actions take place in the following order:
The customized actions of the current action block that failed.
The customized actions that are triggered in any of the previous action blocks.
General Rollback (if enabled).
Different actions to run are available for the different action blocks.
| Action to Run | Description | In Action Blocks... |
|---|---|---|
Command | Enter the command to run in the box along with all necessary parameter values. | Run Command, Run Script |
Script | Drop your script file to run or browse to select the file and enter it in the box. | Run Command, Run Script |
Revert All Files | Deletes any files that were delivered to the devices in this action block and reverts to the files of the previously running version. | Deploy Files, Deploy Artifacts, Release Bundle |
Revert Docker Compose File | Reverts to the previous Docker Compose file that was on the device. | Deploy Container, when you choose Docker Compose as the Deployment Type |
Restart Previous Container | Restarts the previous container version that was running. | Deploy Container, when you choose Single Container as the Deployment Type |
Learn more about Update Deployments.
