deploy.yml

#
# Key: `stages` (optional)
#
# The `stages` list contains a complete list of valid staging environments.  Defaults are dev, uat,
# prod.  If this configuration is removed you will need to add it back to enable additional stages.
#

stages:
  - dev
  - uat
  - prod

#
# Key: `vcs` (required)
#
# Defined settings for the version control system.  Currently only `git` is supported for the
# type.  The path can be any valid `git` URL -- you will need to ensure your deployment user can
# pull from the repo.
#

vcs:
  type: git
  path: git@github.com:symfony/demo.git

#
# Key: `db` (required)
#
# Define database settings for creating, exporting, and importing databases.
#

db:
  # Key: `type` (required) the type of database, e.g. `pgsql`, `mysql`
  type: pgsql

  # Key: `name` (required) the base name of the database, full database names will include stage
  # name and status, e.g. `dev_nmscpa_org`, `dev_nmscpa_org_old`
  name: example_com


  # Key: `host` (option) the host to connect to for DB operations.  Keep in mind that if you
  # are using an inventory file or executing commands on a remote db host, this may be localhost
  # or null (this can be counter-intuitive)
  host:

  # Key: `role` (optional) the user role which owns newly created databases.  This should be equal
  # to the database user that connects from the application.  Defaults to `web` if undefined.
  role: web

  # Key: `user` (optional) the user role which can connect and manage databases.  This will default
  # to the default "root database user" for the database type if undefined.
  user: postgres

  # Key: `pass` (optional) the password for the `user`.
  pass:

#
# Key: 'env` (optional)
#
# A list of environment variables and their values.  These variables will be set on the environment,
# before any code execution and can be used to adjust behavior of supporting commands, e.g.
# `OPUS_DISABLED: 1`.
#

env:
  EXAMPLE_VAR: 1

#
# Key: `options` (optional)
#
# A list of deployment options and their values.  You can overload options on a particular stage
# by adding addtional `options` secitons suffixed by `-<stage>`.  For example, if you want to change
# the default branch on `uat` stage, you can do:
#
# options-uat:
#   branch: testing
#

options:
  # Key: `source` (optional) the stage which data/files are synced to upon deploy, default is `prod`
  source: prod

  # Key: `branch` (optional) is the branch to deploy, default varies on vcs type, `master` for `git`
  branch: master

  # Migration command
  migrate: null

  # Sync method, options are 'dupe' vs. 'transfer'
  sync: transfer

  # Timeout
  timeout: 500

#
# Key: `share` (optional)
#
# A list of files/directories in the stage's shares which will be re-linked to the build.  Shares
# are used for data and configurations that should persist between deployments.  Common entries
# include the `.env` file, storage folders, and possibly session paths.  You can add additional
# per stage shares by adding additional `share` sections suffixed by `-<stage>`.
#

share:
  - .env
  - storage

#
# Key: `build` (optional)
#
# A list of commands which should be executed when building the release.  These commands will be
# executed in the release directory that is currently being built.  Common entries include package
# manager installations, asset building through gulp, webpack, etc.  Per stage build commands can
# be added by creating additional `build` sections suffixed by `-<stage>`.
#

build:
  - npm install
  - gulp build
  - composer install

#
# Key: `sync` (optional)
#
# A list of files/directories in the stage's shares which will be synced to match the source
# stage environment.  If the source for your `uat` stage is `prod`, for example, in addition to
# syncing the database from `prod` down to `uat` upon deployment, these shares will also be synced
# with the shares from that environment.  Additional per stage sync entries can be added by
# creating `sync` sections suffixed by `-<stage>`.
#

sync:
  - writable

#
# Key: `release` (optional)
#
# A list of commands which should be executed when deployment finishes and the new code is finally
# released.  These commands will be executed in from the stage path of the given stage, e.g.
# `stages/prod`.  Common entries include restarting memory caches and/or removing file caches. For
# example `rm -rf storage/cache/*`.  You can add additional per stage release commands by creating
# `release` sections suffixed by `-<stage>`.
#

release:
  - sudo service php7.3-fpm restart