Release/version 0.2.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,61 @@
-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/)
+
+## 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,53 @@
+.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
+
+venv/bin/activate: requirements.txt
+	python3 -m venv .venv
+	$(PIP) install -r requirements.txt
+
+venv: venv/bin/activate
+	. ./.venv/bin/activate
+
+run: venv
+	$(PYTHON) app.py
+
+test: venv
+	$(PYTHON) -m pytest
+
+commit:
+	@echo "Available topics:"
+	@echo "$(TOPICS)"
+	@read -p "Enter the topic for the commit: " topic; \
+	read -p "Enter the commit message: " message; \
+	echo "$${topic}: $${message}" > commit_message.txt; \
+	git add .; \
+	git commit -F  commit_message.txt; \
+	git push; \
+	rm  commit_message.txt
+
+check: venv
+	$(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 {} +
+
+help:
+	@echo "gmake run - run the application"
+	@echo "gmake test - run the tests"
+	@echo "gmake clean - remove all generated files"
+	@echo "gmake check - check for security vulnerabilities"
+	@echo "gmake commit - commit changes to git"
+	@echo "gmake help - display this help"

README.md

@@ -1,135 +1,114 @@
 # tdse-accessForce-bids-api
-Bids API training project with Python and MongoDB
+# API Documentation
 
-# Bid Library
+This API provides an endpoint to post a new bid document.
 
-## Contents
+## Prerequisites
 
-- [Background](#background)
-  - [Before working on a bid](#before-working-on-a-bid)
-  - [Bid phases](#phases)
-- [Brief](#brief)
-  - [Acceptance Criteria](#acceptance-criteria)
-  - [Iterations](#iterations)
+- Python 3.x
+- Flask
+- Homebrew
 
-## Background
+## Running the API
 
-Methods being a consultancy agency to win new work we make to make bids on client tenders.
+1. Clone the repository to your local machine:
 
-- A tender is a piece of work that an organisation (potential client) needs an external team to work on or to supplement an existing team
-- A bid can comprise of several stages to win a tender, usually there are two phases which comprise of phase 1 and phase 2
+      ```bash
+      git clone
+      ```
+2. Navigate to the root directory of the project:
 
-### Before working on a bid
+      ```bash
+      cd tdse-accessForce-bids-api
+      ```
+3. Install python 3.x if not already installed. You can check if it is installed by running the following command:
 
-Before phase 1, there is time for bidders like Methods to ask questions of the client tender. These questions are open to all those looking to bid on the tender and all questions and answers are available to all bidders on a single tender.
+      ```bash
+      python3 --version
+      ```
+4. Install Makefile if not already installed. You can check if it is installed by running the following command:
 
-This step is a necessary is really important for Methods to understand whether we really want to bid on a particular tender. Some considerations before bidding:
+      ```bash
+      make --version
+      ```
+5. Version 3.81 or higher is required. If you do not have Make installed, you can install it with Homebrew:
 
-- Do we like the project and hence want it?
-- Is it good value?
-- Will this get us known with a new client and give Methods leverage in future work?
-- Is the tender something different that would expand our portfolio?
-- Can we do it?
+      ```bash
+      brew install make
+      ```
+6. Run the following command to have all the commands to use the API with Makefile:
 
-### Phases
+      ```bash
+      gmake help
+      ```
+7. Run the following command to start the API:
 
-**Phase 1** compromises of a list of questions set by the tender; in government the scoring system for each question is out of 3, so if there are 6 questions a bidder can achieve a maximum score of 18. The answers to the questions usually have a word limit of 100 or 200 (in this phase).
-
-The client that puts out a tender decides the pass rate in phase 1 to progress to phase 2. The pass rate may not be known until results of all bids are completed for each of the bidders. The list below are common pass criteria you might come across on a bid (remember this can vary from client to client and even within multiple tenders by the same client):
-
-- All questions must have a score greater than 1, (so 2 minimum)
-- A minimum overall score, e.g. 14 out of 18
-- The 3 highest bids assuming the bids met criteria 1 or/and 2
-
-**Phase 2** is a lot more involved than phase 1, it can comprise of a face to face (or virtual) presentation alongside answers to questions limited to x number of words (limit set by client). These questions will cover team culture and technical solution.
-
-There are usually 3 categories that Methods are scored on and these are weighted by the client. The categories are:
-
-- Technical - questions from presentation or form and results from phase 1
-- Culture - questions in phase 2
-- Cost (a.k.a. Rate)
-
-The overall score is worked out as a percentage, (out of 100). Whichever bidder scores highest wins the bid and that is the end of the tendering process.
-
-Next steps: Statement of Work (SoW, the contract) is put together by the client, handing over CVs of potential staff Methods are going to supply and agreement on project start dates.
+      ```bash
+      gmake run
+      ```
+8. The API will be available at http://localhost:8080/api/bids
 
 --------------
 
-## Brief
-
-Currently Methods store all the information for tenders and bids in Sharepoint, the way the documents are stored and the information available can vary quite a lot making it hard for the bid team to find good answers to questions and successful bids for reuse. We currently do not store who helped answering questions against a bid and in some cases where Methods have done so it only informs us of their initials.
-
-What intend to build is an API that can store tender/bid information in a structured way to facilitate finding successful bids and high scoring questions.
-
-### Acceptance Criteria
-
-**Must** have:
-
-1. Ability to access all bid data, see list of data below:
-
-    - tender title
-    - tender short description (problem statement)
-    - client
-    - date of the tender
-    - were Methods successful
-    - what phase did we get to
-    - how well we did in each of the phases
-    - any technologies or skills reuired by client tender
-    - tender questions and Methods answers and the respective scores
-    - who helped answer a question
-    - provide links to further information on bids stored in sharepoint
-    - when was the data last updated
-    - any skills or technologies listed in the answers to questions
-
-1. Ability to find any bid
-1. Ability to add new bids
-1. Ability to update a bid that is still in progress
-1. Ability to delete a bid and associated
-1. Ability to recover deleted bid data within 4 weeks of deletion
-1. Ability to filter bids and questions based on success and score
-1. Ability to sort bids and questions alphanumerically and page through the results
-1. Ability to secure access to changing the data to certain users
-
-**Should** have:
+## Accessing API Documentation (Swagger Specification)
 
-1. Ability to search for bids containing particular text
-1. Ability to search for questions containing particular text
+1. Run the following command to start the API:
 
-**Could** have:
-
-1. Ability to control different user access (permissions) based on roles
-
-    - Admin
-    - Bid writers
-    - Bid viewers
-
-1. Ability to access this software anywhere in the UK
-
-**Would not** have:
-
-1. Due to size of some answers and the content not being soley text but images, diagrams etc. Methods does not wish to duplicate this information from Sharepoint into a filesystem like AWS S3 or Azure Storage
-
-### Iterations
-
-**Iteration 1** Build API and initial storage system to find, add, update and remove. Steps 1 to 8 from Must section
-
-**Iteration 2** Secure the API to users who need access, based on the "Principle least priviledge principle. Step 9 from Must section
-
-**Iteration 3** Build search engine to allow for a more sophisticated way of finding questions and bids related to your needs. Steps 1 and 2 from Should section
-
-**Iteration 4** Expand on access control to bid library based on roles, users and teams where necessary. Step 1 of Could section
-
-**Iteration 5** Host the bid library to be accessed by users across the country. Step 2 of Could section
-
-**Iteration 6** Build a web app to integrate with the bids API, create user journeys that allow users to find, add and update bid content
-
---------------
+      ```bash
+      python app/app.py
+      ```
+2. The Swagger Specification will be available at http://localhost:8080/api/docs
 
-**Note:** If this is part of your training, you should look for guidance by your mentor of how to progress this project. Your coach can use the [generic project rest API doc](/training/generic-projects/rest-api/README.md) to setup your initial project that will cover iteration 1.
 
 --------------
 
-Return to the [internal projects](https://github.com/methods/tdse-projects/blob/main/internal/README.md) for additional options and information.
+## Installing and running an instance of MongoDB on your local machine (MacOS)
+
+### To install on Windows please see [here](https://www.mongodb.com/docs/manual/tutorial/install-mongodb-on-windows/)
+
+1. Install Homebrew if not already installed. You can check if it is installed by running the following command:
+
+      ```bash
+      brew --version
+      ```
+2. Install MongoDB by running the following commands:
+
+      ```bash
+      brew tap mongodb/brew
+      brew install mongodb-community
+      ```
+3. To run MongoDB (i.e. the mongod process) as a macOS service, run:
+
+      ```bash
+      brew services start [email protected]
+      ```
+4. To verify that MongoDB is running, run:
+
+      ```bash
+      brew services list
+      ```
+   You should see the service `mongodb-community` listed as `started`.
+5. Run the following command to stop the MongoDB instance, as needed:
+
+      ```bash
+      brew services stop [email protected]
+      ```
+6. To begin using MongoDB, connect the MongoDB shell (mongosh) to the running instance. From a new terminal, issue the following:
+
+      ```bash
+      mongosh
+      ```
+7. To create a new database called `bidsAPI`, run:
+
+      ```bash
+      use bidsAPI
+      ```
+8. To exit the MongoDB shell, run the following command:
+
+      ```bash
+      exit
+      ``` 
+OPTIONAL - Download MongoDB Compass to view the database in a GUI. You can download it from [here](https://www.mongodb.com/try/download/compass)
 
 --------------