Guides
Guides

Repo Manifest

Overview

Repo Manifest defines how Crafting system automates the setup for a git repository in the workspace after checking out the code. It is in YAML format including the following information:

  • Hooks: define what to do after checkout, and how to build;
  • Daemons: define what should run inside the workspace;
  • Jobs: define what to run based on schedules.

An example:

env: # Environment variables shared by all hooks, daemons and jobs.
- DB_ROOT_PASSWORD=mysql
- RAILS_ENV=development

hooks:
  post-checkout:
    cmd: |
      bundle install
      bundle exec rake db:migrate
  build:
    cmd: |
      bundle exec rubocop

daemons:
  rails: # Name of the process is "rails", which is to launch a rails server on port 3001.
    run:
      cmd: bundle exec rails s -p 3001 -b 0.0.0.0

jobs:
  housekeep: # Name of job is "housekeep", which performs house keeping every 10 minutes.
    run: 
      cmd: ./housekeep  
    schedule: "*/10 * * * *"

Location

The default manifest file in a source repository is .sandbox/manifest.yaml, unless override is specified in Sandbox Definition.

Shared Environment

The top-level section env defines environment variables shared by all hooks, daemons and jobs. Each item must be defined in the form of KEY=VALUE (no spaces around =) where environment extraction $NAME and ${NAME} are supported in VALUE.

Hooks

Hooks are invoked at specific stage during workspace creation or automatic branch follow. The supported hooks are:

HookWhen to Run
post-checkoutOptional, after any new code change pulled from the remote repository.
buildAfter new code change is pulled from the remote repository, and after post-checkout.
If unspecified, no build will be performed.

The value of each hook follows the Run Schema.

All the hooks in the manifest are optional. If unspecified, the script .sandbox/HOOK-NAME will be attempted when the hook is supposed to be invoked. If the script doesn't exist, the hook is simply skipped (treated as success).

Daemons

Daemons are long-running processes in the background. They are automatically launched (after a successful build if build hook is provided). The run property follows the Run Schema. The processes are managed by the workspace and kept running (restarted if failed). And they can be further controlled in the web console, or the CLI commands:

  • cs ps
  • cs restart [NAME]
  • cs stop [NAME]
  • cs start [NAME]
  • cs logs

Jobs

Jobs are one-shot processes executed based on a schedule. The property schedule defines the schedule using crontab format. The run property follows the Run Schema. The process is not restarted if failed.

Run Schema

This schema defines how to run a process:

  • cmd: defines the command line, and will be interpreted by $SHELL -c;
  • dir: defines the working directory, default is the checkout directory of the source repository;
  • env: a list of environment variables in the form of KEY=VALUE (no spaces around =) (overrides Shared Environment) and environment extraction $NAME and ${NAME} are supported.