dist-server

Appearance

Return to top
On this page

Downtime protection

How the Builder protects you from downtime

The Builder is actually pretty simple: it clones or updates a local copy of your repository at the commit that was the HEAD in the webhook delivery. Then it runs a few tasks in a specific order. Every task is revertable and has to clean up its own mess on error. They all have a run, revert and finalize method. When a task fails, every task up to that point will be reverted.

  • run: run the task logic in a non-destructive manner. Create .tmp or .bak files/directories.
  • revert: undo everything that has been done in run.
  • finalize: complete the run method. Remove all backups or rename .tmp files to their definitive name.

Examples

The Builder has the following tasks:

  • Task1
  • Task2
  • Task3

The Builder cloned your repo, now it runs the tasks.

Normal flow:

  • Task1.run() ➡ī¸ ✔ī¸
  • Task2.run() ➡ī¸ ✔ī¸
  • Task3.run() ➡ī¸ ✔ī¸
  • Task1.finalize()
  • Task2.finalize()
  • Task3.finalize()
  • Done, built successfully!

Scenario with a crashing task:

  • Task1.run() ➡ī¸ ✔ī¸
  • Task2.run() ➡ī¸ ✔ī¸
  • Task3.run() ➡ī¸ ❌
  • Task3 manually reverts everything that has to be reverted up to the point of error.
  • Task1.revert()
  • Task2.revert()
  • Done, build failed.

ℹī¸ Notes

  • All Tasks also define a needsToRun getter. This can return true to indicate the Task's run method has to be called, or return false to skip this task. However, it can also decide to crash the build intentionally, for example when something absolutely crucial is missing and the build should be canceled right away.

  • revert and finalize methods can NOT crash, they just can't, because you can't revert after you've already started reverting or finalizing. If you're writing new Tasks or modifying existing ones, do everything you can to prevent errors, and log to Slack whenever a errorous or suspicious scenario occurs.