Deploying a script

A script reaches your cloud in one of two ways: you push it to a connected repository, or you apply it in the editor. Either way it becomes a new version of the environment, Ackee plans it, and nothing is built until a plan is approved.

From a repository

• Commit ackee.ack at the root of the repository, or at the path you choose when connecting it.
• Connect the repository to the project under Deploy on push in the project sidebar, and pick the branch to watch.
• Every push to that branch is read at the pushed commit, checked, and planned. With auto-apply on, a plan that only creates and updates is applied without waiting; a plan that replaces or destroys anything always waits for a person.
• Ackee reports the result on the commit, and the delivery log explains every push it declined — a file with an error is reported with its code and line, and nothing is built.

From the editor

Ackee Script in the project sidebar shows the environment as a script. Edit it and apply, and the canvas redraws from the file; then plan as usual. Applying a script never deploys by itself — that stays one deliberate press.

Going the other way, every change you make on the canvas is reflected in the script. Ackee rewrites only the declarations you changed and leaves the rest of the file — comments, order, blank lines — exactly as it was.

When a deploy fails

A failure is reported against your file. Whether the problem is in the file or the cloud refused a change, the message leads with its code, then the declaration and its line, then the reason — the cloud's own words, when the cloud is the one that said no:

AK504 line 13:1: database "main": creating RDS DB Instance (shop-dev-main): KMSKeyNotAccessibleFault: The specified KMS key [null] either doesn't exist, isn't enabled, or isn't accessible by the current user.
  what this means: https://ackee.dev/docs/language/errors#AK504

The same message is the deployment's status in the list, on your commit, and in the log, and its code's entry in the error reference says what to do. While a deploy runs, the log reports progress the same way — per declaration, as database "main": creating db instance….

The file is the source of truth

For an environment connected to a repository, the committed file is what the environment should be. If someone changes the environment on the canvas, it drifts from the file, and the next push puts it back. To keep a canvas change, open Ackee Script, copy the file, commit it, and push. Ackee never pushes to your repository itself.

Stopping an environment

To stop everything an environment runs, choose Destroy environment in the project sidebar. It opens the danger zone on the Deployments page: type the project's name and press Plan a destroy. That is a plan like any other — it lists every resource it would remove, worked out from what was last applied rather than from the canvas — and nothing is deleted until you approve it.

To remove one thing rather than everything, delete it on the canvas, or its declaration from the file, and plan as usual.

History

Every applied file is kept with the version it produced, so rolling back an environment is deploying an older version — and the file you get back is the one that was written then, comments and all.