Skip to content

Latest commit

 

History

History
94 lines (69 loc) · 5.18 KB

mhs-adaptor-dev-notes.md

File metadata and controls

94 lines (69 loc) · 5.18 KB

MHS Adaptor - Developer Notes

The following sections are intended to provide the necessary info on how to configure and run the MHS adaptor.

Pre-requisites

You'll need to have a connection to Spine. For testing purposes, you can use Opentest. See Setup an OpenTest connection for details.

Finally, ensure you have Pipenv installed and on your path, then within each of the subfolders common, inbound and outbound in this directory, run:

pipenv install

Developer Setup

To prepare a development environment for this application, ensure you have Pipenv installed and on your path, then within each of the subfolders common, inbound and outbound in this directory, run:

pipenv install --dev

If the build fails due to dependency issues with proton, follow these instructions:

  1. Visit: https://visualstudio.microsoft.com/downloads/
  2. Download the 'Community Edition'
  3. Run the installer once the download has completed
  4. Select the Desktop development with C++ workload option
  5. Once the installation has completed you may have to reboot.

Running the MHS Adaptor locally

The MHS Adaptor is made up of multiple components, and running them all separately can be tedious. Instead, follow the steps described in running an MHS Adaptor locally for how to run the required set of docker containers locally.

API docs

MHS outbound (which is the API that suppliers use to make requests to the MHS) is documented using OpenAPI. These docs can be generated by running pipenv run generate-openapi-docs in the mhs/outbound folder. The output of this command can be saved to a file, then transformed into another format (eg client SDK, HTML docs) using various OpenAPI tools available online. For example:

pipenv run generate-openapi-docs > test.json
docker run --rm -v ${PWD}:/local  openapitools/openapi-generator-cli generate -g html -i /local/test.json -o /local/out/html

generates HTML docs. An invocation of this command can be seen here.

Running Unit Tests

  • pipenv run unittests will run all unit tests.
  • pipenv run unittests-cov will run all unit tests, generating a Coverage report in the test-reports directory.
  • pipenv run coverage-report will print the coverage report generated by unittests-cov
  • pipenv run coverage-report-xml will produce an XML version of the coverage report generated by unittests-cov, in a Cobertura compatible format
  • pipenv run coverage-report-html will produce an HTML version of the coverage report generated by unittests-cov

Coverage

pipenv run unittests-cov will run all unit tests with coverage enabled.
pipenv run coverage-report-xml will generate an xml file which can then be submitted for coverage analysis.

Analysis

To use sonarqube analysis you will need to have installed sonar-scanner.
Ensure sonar-scanner is on your path, and configured for the sonarqube host with appropriate token. (See: SonarQube)
sonar-scanner will use sonar-project.properties to submit source to sonarqube for analysis.
NOTE: Coverage will not show in the analysis unless you have already generated the xml report (as per above.)

Running Integration Tests

See the integration tests README.

Timeouts received whilst waiting for a response from Spine on a Windows machine could be due to the machine rejecting incoming connections on port 443. In order to open the port, follow these instructions: https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-firewall/create-an-inbound-port-rule

Any content POSTed to / on port 80 will result in the request configuration for the Interaction-Id header in data/interactions.json being loaded and the content sent as the body of the request to Spine. Adding entries to interactions.json will allow you to define new supported interactions.

Creating a release

Releasing the main images

First identify which is the most recent commit within GitHub which contains only changes which are marked as Done within Jira. You can also review what commits have gone in by using the git log command or IDE.

Make a note of the most recent Release within GitHub, and identify what the next version number to use will be.

Create a new release within GitHub, specifying the tag as the version to use (e.g. 1.2.9), and the target being the commit you identified. Click on the "Generate release notes" button and this will list all the current changes from the recent commit. Click the "Publish release" button, this will start an automated GitHub Actions workflow to publish the images to Dockerhub for the new version.

Update the CHANGELOG.md file, adding a new version header for all the changes being released. Raise a PR for your changes.