-[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.
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).
