While Seed does not need a build spec to configure your pipelines or your project, there are cases where you need to run some scripts during the build process. You can get a sense of the different build steps by looking at one of your build logs.
To hook into the build process, add a
seed.yml in the root of your project directory. Here is the basic skeleton of our build spec.
before_compile: - echo "Before compile" before_build: - echo "Before build" before_deploy: - echo "Before deploy" after_deploy: - echo "After deploy" before_remove: - echo "Before deploy" after_remove: - echo "After deploy"
Below is a brief description of when these commands are run.
Seed starts the build process by doing a
npm install(for Node.js projects),
pip install -r requirements.txt(for Python projects), or
make(for Go projects). The
before_compilestep let’s you run commands before this. This can be useful for configuring private npm modules. This step is not run when a build is promoted to production.
The actual build portion for Seed is the
serverless packagecommand that creates the build. The
before_buildstep let’s you run your commands before this happens. This step is not run when a build is promoted to production.
After the build packages are created, Seed deploys these using the
serverless deploycommand. The
before_deploylet’s you run your commands before this happens. This step is run for all builds and also when they are promoted to production. You can distinguish between the cases by using the
$SEED_STAGE_NAMEbuild environment variable.
After the deployment is complete you can use the
after_deploystep to run any post deployment scripts you might have. Again, this step is run for all builds and also when they are promoted to production. You can distinguish between the cases by using the
$SEED_STAGE_NAMEbuild environment variable.
Seed runs the
serverless removecommand to remove a deployed service. The
before_removestep let’s you run any commands before this happens. Note that, this step is only run when a service is being removed.
Similar to the
after_removestep is run after a service has been removed. This can be used to run any cleanup scripts you might have.
Build Environment Variables
Seed also has a couple of build environment variables that you can use to customize your build process. These should not be confused with the secret environment variables that are defined in the console.
$SEED_STAGE_NAME: The name of the stage that is being built. The stage names are exactly as shown in the console.
$SEED_STAGE_BRANCH: The name of the git branch the stage is auto-deployed from. If the stage is not auto-deployed, the value is not defined.
$SEED_APP_NAME: The app name.
$SEED_SERVICE_NAME: The name of the service.
$SEED_BUILD_ID: The build id.
$SEED_BRANCH: The Git branch used to trigger this build. Does not apply to promotions and rollbacks. For PR stages, this is the branch the PR was submitted to. Note the difference between this and the
$SEED_STAGE_BRANCHvariable. These two variables will differ if you trigger a manual deployment using a branch that’s different from the one the stage is set to auto-deploy from.
$SEED_PULL_REQUEST_NUMBER: For PR stages, this is the number of the Pull Request.
- Secrets: All your secrets in the Seed console are also made available during the build process. For example, a secret environment variable called TEST_VAR would be available as
$TEST_VARin the build process.
For example, let’s take a build URL in the console:
$SEED_APP_NAME would be
$SEED_STAGE_NAME would be
$SEED_SERVICE_NAME would be
$SEED_BUILD_ID would be
Custom Build Environment Variables
Environment variables that are set in the build spec do not persist across commands. This means that in the following build spec,
$MY_VAR will not be printed out.
before_compile: - export MY_VAR=hello - echo $MY_VAR
To ensure that your custom build environment variables persist across commands; Seed allows you to do something similar to CircleCI. You export your custom environment variables to a
$BASH_ENV and Seed will load that on every command.
So a variation of the above with
$BASH_ENV looks like this:
before_compile: - echo 'export MY_VAR=hello' >> $BASH_ENV - echo $MY_VAR
In this case
$MY_VAR is loaded from
$BASH_ENV and should be printed out correctly.
You can also add the following to your
seed.yml to deploy all your services without checking if anything has been updated.
The scripts in your build spec are run in an environment that are using your AWS IAM credentials. This means that you can directly use any AWS commands in your script using the AWS CLI without having to configure it.
Build Spec Examples
Here are a couple of examples of what you could do in a build spec.
Run a script after deploy only in prod
Let’s assume your production stage is called
after_deploy: - if [ $SEED_STAGE_NAME = "prod" ]; then echo 'deployed prod'; fi
Run a script after deploying a specific service
Let’s assume your service is called
after_deploy: - if [ $SEED_SERVICE_NAME = "users" ]; then echo 'deployed users'; fi
If you need to start a PostgreSQL server locally for tests.
before_compile: - apt-get install wget ca-certificates -y - wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | apt-key add - - sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt/ `lsb_release -cs`-pgdg main" >> /etc/apt/sources.list.d/pgdg.list' - apt-get update - apt-get install postgresql postgresql-contrib -y