Release/version 0.3.0

.gitignore

@@ -2,7 +2,6 @@
 __pycache__/
 *.py[cod]
 *$py.class
-
 # C extensions
 *.so
 
@@ -127,6 +126,9 @@ venv/
 ENV/
 env.bak/
 venv.bak/
+commit_message.txt
+./commit_message.txt
+
 
 # Spyder project settings
 .spyderproject

.vscode/settings.json

@@ -0,0 +1,6 @@
+{
+    "[python]": {
+        "editor.defaultFormatter": "ms-python.black-formatter"
+    },
+    "python.formatting.provider": "none"
+}

CONTRIBUTING.md

@@ -1,10 +1,82 @@
-Contributing guidelines
-=======================
+# Contributing guidelines
 
-### Git workflow
+## Git workflow
 
-* Use git-flow - create a feature branch from `develop`, e.g. `feature/new-feature`
+* Use git-flow - create a feature branch from `develop`, e.g. `feat/new-feature`
 * Pull requests must contain a succinct, clear summary of what the user need is driving this feature change
 * Ensure your branch contains logical atomic commits before sending a pull request
 * You may rebase your branch after feedback if it's to include relevant updates from the develop branch. It is preferable to rebase here then a merge commit as a clean and straight history on develop with discrete merge commits for features is preferred
 * To find out more about contributing click [here](https://contributing.md/)
+
+## Branching
+* Branches should be named in the following format:
+  ```textbox
+  <type>/<description>
+  ```
+  where `type` is one of the following:
+    ```textbox
+    * fix: for a bug fix
+    * feat: for a new feature
+    * docs: for documentation changes
+    * style: for changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
+    * refactor: for refactoring production code
+    * test: for adding tests
+    * chore: for updating build tasks, package manager configs, etc
+    * build: for changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
+    ```
+  and `description` is a short description of the feature or fix being made
+  * e.g. `feat/new-feature` or `fix/bug-fix`
+* Branches should be created from the `develop` branch
+* Branches should be merged back into the `develop` branch
+
+## Commit messages
+
+Please use the following format for commit messages:
+
+```textbox
+* fix: for a bug fix
+* feat: for a new feature
+* docs: for documentation changes
+* style: for changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
+* refactor: for refactoring production code
+* test: for adding tests
+* chore: for updating build tasks, package manager configs, etc
+* build: for changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
+```
+
+## Pull requests
+
+* Pull requests should be made to the `develop` branch
+* Pull requests should be made from a feature branch, not `develop`
+* Pull requests should be made with a succinct, clear summary of what the user need is driving this feature change
+* An automated template will be provided to help with this process, please fill it out as best you can
+
+## Release branches and Tagging
+
+* Once a single or set of changes has been made that can be released, we create a release branch off develop
+  * Releases should be as small as possible so that it is easier to fix issues and rollback code in production environment without losing many features at once
+  * Release branches should be of the following structure:
+
+    ```sh
+    release/0.1.0
+    ```
+
+  * The release name should abide by [semantic versioning (semver)](https://semver.org/)
+* Once release branch has been created, a pull request should be made against the `main` branch
+* Once approved, the release branch can be merged locally :warning: **WARNING - Do not push to remote** :warning:
+* Tag the release and push to remote - [see tagging](#tagging)
+
+## Tagging
+
+* Tag latest commit on branch, this should be the local merge commit
+  * Check latest local commit, run: `git show HEAD`
+  * Create tag, run: `tag -s <tag> -m <message>`
+    * where `tag` is the semver value (should be taken from the release branch name) and `<message>` is a general, short and concise message of the change
+* Push release merge and tag to remote, run: `git push --follow-tags`
+* Once pushed, go to the Github releases page for the repository in question, which can be found by clicking on the <> Code tab and clicking on Releases on the right hand side:
+  * Select Tags
+  * Click on the v0.1.0 tag that you just created
+  * Choose Create release from tag
+  * Copy the release name and make human-friendly (capitalise, remove /) to create a release title (e.g. release/0.1.0 -> Release 0.1.0)
+  * Add relevant release notes, this can be expanded from initial message created against the tag. Advised to use bullet points to list out changes
+  * Hit Publish release

Makefile

@@ -0,0 +1,96 @@
+.ONESHELL:
+
+.DEFAULT_GOAL := run
+TOPICS := fix - feat - docs - style - refactor - test - chore - build
+
+
+PYTHON = ./.venv/bin/python3
+PIP = ./.venv/bin/pip
+
+
+.PHONY: run test clean check help commit swagger format branch lint setup bids dbclean
+
+help:
+	@echo "gmake help - display this help"
+	@echo "gmake bids - create sample data"
+	@echo "gmake branch - create a new branch"
+	@echo "gmake build - create and activate virtual environment"
+	@echo "gmake check - check for security vulnerabilities"
+	@echo "gmake clean - remove all generated files"
+	@echo "gmake commit - commit changes to git"
+	@echo "gmake dbclean - clean up the application database"
+	@echo "gmake format - format the code"
+	@echo "gmake lint - run linters"
+	@echo "gmake run - run the application"
+	@echo "gmake swagger - open swagger documentation"
+	@echo "gmake setup - setup the application database"
+	@echo "gmake test - run the tests"
+
+bids:
+	@echo "Creating sample data..."
+	@find . -name "create_sample_data.py" -exec python3 {} \;
+
+branch:
+	@echo "Available branch types:"
+	@echo "$(TOPICS)"
+	@read -p "Enter the branch type: " type; \
+	read -p "Enter the branch description (kebab-case): " description; \
+	git checkout -b $${type}/$${description}; \
+	git push --set-upstream origin $${type}/$${description}
+
+build: venv/bin/activate
+	. ./.venv/bin/activate
+
+check:
+	$(PIP) install safety
+	$(PIP) freeze | $(PYTHON) -m safety check --stdin
+
+clean:
+	@echo "Cleaning up..."
+	@find . -name "__pycache__" -type d -exec rm -rf {} +
+	@find . -name ".pytest_cache" -exec rm -rf {} +
+	@find . -name ".venv" -exec rm -rf {} +	
+
+commit: format
+	@echo "Available topics:"
+	@echo "$(TOPICS)"
+	@read -p "Enter the topic for the commit: " topic; \
+	read -p "Enter the commit message: " message; \
+	git add .; \
+	git commit -m "$${topic}: $${message}"; \
+	git push
+
+dbclean:
+	@echo "Cleaning up database..."
+	@find . -name "delete_db.py" -exec python3 {} \;
+
+format: 
+	$(PIP) install black
+	$(PYTHON) -m black .
+
+lint:
+	$(PIP) install flake8 pylint
+	$(PYTHON) -m flake8 
+	$(PYTHON) -m pylint **/*.py
+
+run: build
+	$(PYTHON) app.py
+
+setup: build dbclean bids
+	@echo "Setting up the application database..."
+
+swag:
+	open http://localhost:8080/api/docs/#/
+
+test: test_setup
+	coverage run -m pytest -vv
+	@echo "TEST COVERAGE REPORT"
+	coverage report -m --omit="tests/*,dbconfig/*"
+
+test_setup: test_requirements.txt
+	$(PIP) install -r test_requirements.txt
+
+venv/bin/activate: requirements.txt
+	python3 -m venv .venv
+	$(PIP) install -r requirements.txt
+