Whenever you deploy code, or change a config var, or remove (or add) an add-on resources you implicitly create a new release and automatically will cause your application to restart. You can see a history of releases, and roll back a release to revert the prior changes (if needed) through the CLI (
aka releases:rollback), UI or Platform Apps API.
Releases are named
vNNN where the
NNN indicates the release id. The release's are sequential and unique to the application. One way to create a release is by manually providing a set of sources to build.
aka releases:create https://example.com/source_code.zip -a myapp-myspace Deploying https://example.com/source_code.zip to myapp-myspace ... ✓
You can also trigger a new release by commiting into a branch on a source control repository Akkeris is watching.
git commit -a -m 'My commit message' ; git push remote: Counting objects: 75, done. remote: Compressing objects: 100% (53/53), done. remote: Total 62 (delta 27), reused 44 (delta 9) Unpacking objects: 100% (62/62), done.
aka releases -a myapp-myspace • v1 1 minute ago Auto-Deploy 6d58b1ce - User (username) - My commit message - ef5c71a
Attaching your app to a repository
If you'd like your application to build on a commit, you can do so by telling Akkeris to watch a repository for your application.
aka repo:set -a myapp-myspace https://github.com/org/repo the_branch_to_watch -u github_username -t github_token
Note that if you do not specify a branch by default
master is watched. In addition, if your installation has a default service account for Github installed leaving off the username and token will cause Akkeris to try and use the default service account instead.
Generating a Github token
github_token must be a personal access token generated by a user who has administrative access to the specified repo and the scopes:
You can generate a personal access token on Github by going to https://github.com/settings/tokens and following the instructions.
Listing Release History
To see the history of releases for an app:
aka releases -a myapp-myspace • v1 16 days ago Auto-Deploy 6d58b1ce - GithubUser2 (Github User 1) - Another commit - ef5c71a • v2 14 days ago Auto-Deploy e08c02cb - GithubUser3 (Github User 2) - Some merge commit - 3ad31be • v3 10 days ago Auto-Deploy cbc06f1b - GithubUser1 (GithubUser 3) - yet another - ece6039 • v4 9 days ago Auto-Deploy 52aeae74 - c4357b9
Use the rollback command to revert to the previous release:
aka rollback -a myapp-myspace Rolling back to v3 on myapp-myspace
You may choose to specify another release to target:
aka rollback v1 -a myapp-myspace Rolling back to v1 on myapp-myspace
Rolling back will create a new release which is a copy of the state of the compiled slug and config vars of the release specified in the command. The state of your source code repository, database, and external state held in add-ons (for example, the contents of memcache) will not be affected and is your responsibility to reconcile with the rollback.
Running on a rolled-back release is meant as a temporary fix to a bad deployment. If you are on a rolled-back release, fix and commit the problem locally, and re-push to akkeris.
Building From Sources
If a new release is creating by specifying a url to a zip, tar-gzipped file or from a Github commit akkeris will look for a
Dockerfile at the root for instructions on how to build the application. Akkeris will add any non-service (user specified) config vars and build arguments to the docker build. In addition, if the build came from a source control commit the build args
AKKERIS_GIT_REPO will be added.