Merge branch '78-document-how-to-use-a-clean-install-to-develop-drumk…

…it-directly' into 'master'

Resolve "Document how to use a clean install to develop drumkit directly"

Closes #78

See merge request consensus.enterprises/drumkit!42

docs/content/development/testing.md

@@ -15,10 +15,25 @@ 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 (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.
+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.

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`.
 

docs/content/usage/hugo-docs.md

@@ -27,12 +27,25 @@ The automatically generated starting point is in `docs/content/_index.md`. To pu
 
 For guidance on using hugo to layout your docs site, refer to [hugo documentation](https://gohugo.io/getting-started/usage/)
 
+### Local testing
+
+Initialization of the hugo docs site with drumkit includes the addition of a `gitlab-ci.yml` file at the root of the project.
+
+This file is used by gitlab-runner to trigger the CI tests.
+
+**If you cloned using the development script, you will need to update the URL of the .mk submodule manually for these tests to run successfully.**
+
+Edit the submodule information in `.gitmodules` at the root of the containing project. Change the URL of .mk to: https://gitlab.com/consensus.enterprises/drumkit.git
+
+
 ### Deployment
 
 The deployment to Gitlab Pages is managed automatically by the `.gitlab-ci.yml` file.
 
 At the bottom of the file, under `pages`, the `publish` stage will run `hugo` in the docs folder, which generates a set of static HTML files in the `public` folder, which is then made available through Gitlab pages.
 
+
 The address at Gitlab Pages will be `http://<GITLAB_GROUP>.gitlab.io/<GITLAB_PROJECT_NAME>/`
 
 To set up your Gitlab Pages, you need to update the configuration in `docs/config.yaml`, which is set to "http://mygroup.gitlab.io/myproject". 
+

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