One common use for Docksal outside of local development is for running CI (continuous integration) tasks with services like TravisCI, CircleCI, or Bitbucket Pipelines.
You might want to use Docksal for CI for the same reasons that you use Docksal for local development.
Depending on which service you’re using for your CI, the steps may be a little different, but the outcome is the same. We’re not going to cover setting up CI with your project’s repo in this training, but we will cover how to use Docksal in that service.
We’re going to use TravisCI for our scenario here.
In TravisCI, we are given a blank slate to work with, meaning we can set it up however we want and run whatever commands are needed in order for the project to spin up and run tests. Travis, like many CI services, runs commands based off of a YAML file. We’re only going to cover TravisCI from a very high level as it pertains to using Docksal for CI.
Let’s take a look at a very basic .travis.yml file using Docksal and break it down:
sudo: required
language: generic
dist: xenial
services:
- docker
install:
- bash <(curl -fsSL https://get.docksal.io)
- fin version
- fin sysinfo
before_script:
- travis_retry fin init
script:
- fin testsLet’s take a look at what this does:
sudo: required
language: generic
dist: xenialsudo available to our CI environment. This is needed for some of the commands the Dockerfile runs.generic language which covers what we need to run the commands we’re going to run.xenial distribution of Ubuntu.services:
- docker
install:
- bash <(curl -fsSL https://get.docksal.io)
- fin version
- fin sysinfoCheck that Docksal is installed by running fin version and fin sysinfo.
If either of these commands fail, then we get a failed build and we’ll have to look into it. If they succeed, then we can continue on.
before_script:
- travis_retry fin init
script:
- fin testsfin init runs to spin up our project. If it fails during this step, our build fails and we need to find out why.
NOTE: We prefixed this with travis_retry. This is a wrapper that will retry the following command 3 times before failing. Useful in the event that the healthcheck gets hung up or composer has issues.fin tests which would be a custom command that defines tests to be run for a site. These can be PHPUnit, Behat, Cypress, Backstop, or any other type. Usually the command would be a wrapper for fin exec phpunit... or similar.If we wanted, we could create a custom command to run specifically for CI. This may be called init-ci and contain steps that are only important to testing or deploying within a CI environment.
We could also setup custom Docksal variables and services in docksal-ci.env and docksal-ci.yml by setting the DOCKSAL_ENVIRONMENT=ci environmental variable.
Let’s say that even though you’re using a host like Acquia and the Acquia stack on local, you don’t need everything installed. You could probably do without Varnish, Memcache, and Solr. We could adjust these for the build by creating docksal-ci.env and docksal-ci.yml.
First, we would add
env:
global:
- DOCKSAL_ENVIRONMENT=cito .travis.yml.
Then create our docksal-ci.env file
$ cd .docksal
$ touch docksal-ci.envOpen this file and add
DOCKSAL_STACK="default"At this time, we don’t need to change our PHP version or anything, so we won’t create docksal-ci.yml.
Docksal can be used for more than just local development. It can be used for CI and deployments and configured to run almost anything that you might need in a CI environment. Another use case is for setting up a sandbox environment on a server to test feature or show off projects. You can read more about that in the blog post Installing Docksal on a remote server.