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:

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), unless disable_on_start: true is specified (see Disable On Start ). 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 property disable_on_start set to true can be used to not schedule the job after workspace start (see Disable On Start ). The run property follows the Run Schema. The process is not restarted if failed.

Disable On Start

Both Daemons and Jobs supports the property disable_on_start to not start/schedule after workspace startup. For example:

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
    disable_on_start: true

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

This has the effect to not start the daemon or schedule the job after workspace startup. Later, the daemon and job can be manually started/scheduled from either the UI or CLI.

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.