Update instructions for gitlab-runner.

docs/content/development/testing.md

@@ -15,4 +15,27 @@ You can test the installation by running `behat` (it just checks for correct ins
 
 To run the tests specific to the component you are developing, navigate to `.mk` and run `behat {filename}` for the component. For example, to run the tests for the hugo project, run `behat features/projects/hugo-docs.feature`
 
-These are the tests most likely to break and fail when you push a change, so they should be run locally before pushing to the repo. The CI process runs the complete behat suite on all branches, so this is the quickest way to prevent pipeline failures.
+These are the tests most likely to break and fail when you push a change, so they should be run locally before pushing to the repo. 
+
+The CI process (when you push changes to the [drumkit project](https://gitlab.com/consensus.enterprises/drumkit) on gitlab) runs the complete `behat` suite on any branch, not just master. Running the tests locally before pushing changes is a relatively easy way to prevent pipeline failures.
+
+This is not to say that you won't have pipeline failures; it will just catch the ones that break any tests associated with the code you just wrote.
+
+**Important Note on Local Testing**
+
+Drumkit includes the ability to install `gitlab-runner` locally, which will run through the entire build in the `.gitlab-ci.yml` file. 
+
+To run the pipeline on a *project* that you are developing: 
+- Install gitlab-runner using `make gitlab-runner`
+- Run the section of the `.gitlab-ci.yml` using `gitlab-runner exec docker <test-section>`
+
+Some of the projects have a `ci-local` target (or a `<project>-ci-local` target), but this feature is still in development. This will be updated as the solution is standardized. 
+
+However, there is a limitation in `gitlab-runner`: You cannot navigate into the `.mk` directory and run the pipeline at that level, because it cannot parse the relative paths to the subdirectory, which must be used as the repo for the pipeline. [More info on the gitlab ticket - not ours to fix](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2054)
+
+## Testing the output from Drumkit
+
+The ultimate test of Drumkit is that it pushes working code to the (surrounding/containing) project you are working on with it.
+
+Process:
+If you are developing Drumkit, per se, you should test and push the project as well as the drumkit code. This ensures that any modifications we make to (for example) `.gitlab-ci.yml` templates produces the correct files in the end.

docs/content/usage/drupal.md

@@ -30,7 +30,7 @@ git init
 
 wget -O - https://drumk.it/installer | /bin/bash
 . d
-make init-project-drupal8
+make init-project-drupal
 ```
 
 This will prompt you for some information to populate your project:
@@ -113,7 +113,7 @@ recent `make snapshot` was taken.
 By passing a name or short description to these targets, one can save and
 restore multiple snapshots at different states or stages of development. The
 [code providing this
-feature](https://gitlab.com/consensus.enterprises/drumkit/-/blob/master/files/drupal8/50_backup.mk)
+feature](https://gitlab.com/consensus.enterprises/drumkit/-/blob/master/files/drupal-project/50_backup.mk)
 largely manages these symlinks, creating and using them, as well as listing or
 removing them using `make ls-snaps`, `make rm-snap` and `make rm-all-snaps`.
 

features/projects/drupal-project.feature

@@ -1,4 +1,4 @@
-@init @drupal8 @project
+@init @drupal @project
 Feature: Initialize Drupal projects with Lando.
   In order to start a new Drupal project in a Lando environment
   As a Drupal Developer