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

…it-directly' into 'master'

Add instructions on local tests

See merge request consensus.enterprises/drumkit!37

docs/content/development/_index.md

@@ -1,7 +1,6 @@
 ---
 title: Development How-To's
 weight: 30
-draft: false
 
 ---
 
@@ -14,3 +13,4 @@ TOPICS:
 * Making new kinds of projects
 * Documentation (see above maintaining-drumk.it)
 * [Contributing to Drumkit](contribute)
+* [Testing](testing)

docs/content/development/mustache.md

@@ -10,8 +10,9 @@ project codebases, etc.
 
 We are using the GoLang implementation of mustache because it is available as a
 self-contained binary for easy download.  To use it in a project, you need to have installed
-mustache by running `make mustache` first; in a Makefile, ensure you have listed it
-as a dependency so it gets installed before you try to use it, e.g.:
+mustache by running `make mustache` first. 
+
+If you are using for templating in a Makefile, list it as a dependency so it gets installed before you try to use it, e.g.:
 
 ```
 config.yml: mustache

docs/content/development/self-docs.md

@@ -4,7 +4,7 @@ weight: 50
 draft: true
 ---
 
-This text is coming from the docs folder inside the drumkit project.
+This text (what you are reading right now) is coming from the `docs` folder inside the drumkit project.
 
 However, Drumkit also has a self-documentation feature built in to provide command line assistance for the most common tasks.
 

docs/content/development/testing.md

@@ -0,0 +1,18 @@
+---
+title: Drumkit Testing
+weight: 40
+---
+
+Drumkit is developed using a BDD approach with behat as the testing (suite?)
+
+The tests are located in the `.mk/features` directory.
+
+To run the tests locally, you need to install behat in the project.
+
+Navigate to the root directory of the project (the one above `.mk`) and run `make init-behat`
+
+You can test the installation by running `behat` (it just checks for correct installation of behat).
+
+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.

docs/content/usage/hugo-docs.md

@@ -33,4 +33,4 @@ The deployment to Gitlab Pages is managed automatically by the `.gitlab-ci.yml`
 
 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 default address at Gitlab Pages will be 
+The address at Gitlab Pages will be `http://<GITLAB_GROUP>.gitlab.io/<GITLAB_PROJECT_NAME>/`

mk/tasks/docs.mk

@@ -1,10 +1,10 @@
 # Build and serve our docs site locally.
 
-.PHONY: docs docs-kill
+.PHONY: docs-start docs-kill
 
 HUGO_SERVE_CMD=hugo serve --noHTTPCache --quiet --disableFastRender
 
-docs: ## Run Hugo server locally in the background (http://localhost:1313).
+docs-start: ## Run Hugo server locally in the background (http://localhost:1313).
 	cd docs && $(HUGO_SERVE_CMD) 2>&1 > /dev/null &
 
 #TODO add support to kill local server on a mac