Commit 47089533 authored by Niall McDaid's avatar Niall McDaid Committed by Niall McDaid
Browse files

auth tokens and merging policies

parent b3e5c29a
......@@ -5,10 +5,13 @@
- [Development Setup](#development-setup)
- [Package Dependencies](#package-dependencies)
- [OSDU Authorization Tokens](#osdu-authorization-tokens)
- [Refresh Tokens](#refresh-tokens)
- [Linting and Tests](#linting-and-tests)
- [Architecture](#architecture)
- [Repository Structure](#repository-structure)
- [Branching and Merge Policies](#branching-and-merge-policies)
- [Branching](#branching)
- [Merge Requests](#merge-requests)
- [Package Deployment and Installation](#package-deployment-and-installation)
- [Install from Repository Source](#install-from-repository-source)
- [Publish to the Package Registry](#publish-to-the-package-registry)
......@@ -53,7 +56,16 @@ pipenv install <package_name>
### OSDU Authorization Tokens
The Wellbore DDMS API that this system communicates with uses token based authentication
The Wellbore DDMS API that this system communicates with uses token based authentication.
A token can be acquired using the POST request defined in the 'Azure Auth' Postman collection (see file `csp-auth-postman/Azure-Auth.postman_collection.json`). This JSON file can be imported into a Postman workspace as a collection and the 'Get Bearer Token - Wellbore DDMS' request run from there.
#### Refresh Tokens
The body of the 'Get Bearer Token' request requires a refresh token to continue working - these expire after a period of ~90 days so will need to be updated.
There are two options for getting this:
- Each time the POST request for a new bearer token is made, a new refresh token will be returned as well. This refresh token can be copied into the body of the request.
- If the refresh token has expired, meaning the POST request for a new token cannot be made, the Cloud Service Provider (CSP) will need to be contacted and they can provide a new token. This could be Microsoft, IBM, Google Cloud Platform (GCP) or Amazon Web Services (AWS).
### Linting and Tests
......@@ -83,6 +95,17 @@ Include a listing of the purposes of modules in here.
## Branching and Merge Policies
### Branching
For each issue being worked on, a new branch based on `main` should be created for all work related to that task to be committed to.
Branch naming convention: "\<issue number>-summary-of-task" (e.g. *46-write-system-maintenance-guide*)
### Merge Requests
When the work is complete a merge request (MR) can be opened to merge the development branch into `main`. Once the code has been reviewed and the MR approved by at least one other developer, the MR can be completed.
The following guidance should be followed where possible:
- The creator of a MR (i.e. the developer that completed the work) should not approve their own MR (unless the work completed is very minor).
- The creator of a MR should be the one to complete the MR once approved (not the person that has reviewed/approved it).
## Package Deployment and Installation
- OSDU Authorization Tokens
- Architecture
- Repository Structure
- Branching and Merge Policies
- Tidy up README - make it very user friendly (not for developers, purely for users)
\ No newline at end of file
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment