The next step is to implement a custom sub-theme. I have a lot of experience with Bootstrap, and there is a great Drupal project that is feature rich and well maintained.
Getting the main theme installed was pretty straight forward, with most of the work updating the Drupal Runner CI script to make it all work.
Create the Drupal Sub-Theme
Enabling the ‘Bootstrap’ theme was as simple as drush pm-enable bootstrap -y
and drush vset theme_default bootstrap
.
From there it got a bit trickier.
The official documentation has a nice list of instructions, and for me they went something like this:
- Duplicate the
bootstrap/starterkits/sass
directory as its own folder in thesites/all/themes
directory. - Rename the sub-theme directory to
ark
- Is this too short? It might conflict with this ‘Ark’ project.
- Rename
sass.starterkit
toark.info
- Edit the information inside
ark.info
- Clone the current Bootstrap repo from GitHub into the sub-theme as
bootstrap
- Be sure to remove the embedded
.git
directory inbootstrap
. It’s not needed and also huge.
- Be sure to remove the embedded
- Install and enable the
jQuery Update
module. - Compile the sass to
css/style.css
- Use the command
sass sass/style.scss:css/style.css
- This actually is a small typo in the official docs. (it currently says ‘styles.css’)
- It just has to match the line in
ark.info
:stylesheets[all][] = css/style.css
- Use the command
- Add
sites/all/themes/ark/.sass-cache
to the repo.gitignore
file.
Ideally the compiled css won’t be stored in the repo, but build and moved by the CI deployment script. This is enough to get off the ground though.

Updating the CI script
Previously the Drupal Runner script was removing the entire sites
directory and linking it to the shared
directory. However, I forgot the themes live in there, so I refactored it to symlink the settings.php
file instead.
Additionally, the drush
command was not found by the gitlab-runner
user, which meant the bash PATH
was not being exported correctly during first login. Since the login is non-interactive, some of the profile files weren’t loading. I couldn’t get it to load consistently (at all), so I opted to export the ~/.composer
directory to the PATH
right in the .gitlab-ci.yml
file during before_script
.
Remote Configuration with Drush commands
Most importantly, I needed a way to configure the remote staging database during the push. This way drush
commands are run automatically on git push
deployments, and I don’t have to go the remote server to configure everything in the admin by clicking.
Updating WordPress and Drupal remote configurations is awful because of all the damn clicking.
~ Me
There seems to be a few ways to perform this task (which might call for more research later, especially for the Features module), but ultimately I decided to create a /scripts/releases.sh
file in the root of the Drupal project. This file is then run during the deploy
script


