fix(format): Formatting fixes (#517)

## Introduction
Formatting fixes

---------

Co-authored-by: Abhi Markan <[email protected]>

.github/workflows/README.md

@@ -1,17 +1,19 @@
 # Git Hub Actions (GHA) 🚀
+
 GitHub Actions has been widely used to define custom workflows (using YAML syntax) to build, test, lint and deploy out code directly from our public GitHub repositories.
 
 ## Infrastructure
 
-This is a GitHub Action that creates the infrastructure for an APIM (Azure API Management) system. It sets up a base infrastructure in Azure, creates a container registry, virtual network, container app environment, and defines IP restrictions. After the setup is complete, it configures the APIM system by creating a product and importing an API. 
-The action runs on Azure with the self-hosted, APIM, and infrastructure tags. It triggers when a push is made to the infrastructure branch and runs only when the infrastructure.yml file within the .github/workflows directory is modified. 
-The action defines several environment variables for the product, environment, target, and timezone. It configures the Azure CLI defaults, logs in to Azure, and creates a resource group, container registry, virtual network, and container app environment. 
-It then sets IP restrictions and configures the APIM system by creating a product and importing an API. The product is named apim-{product}-mdm, and the imported API has the display name MDM with the path /mdm. The API is imported from a container app environment that was created earlier. 
+This is a GitHub Action that creates the infrastructure for an APIM (Azure API Management) system. It sets up a base infrastructure in Azure, creates a container registry, virtual network, container app environment, and defines IP restrictions. After the setup is complete, it configures the APIM system by creating a product and importing an API.
+The action runs on Azure with the self-hosted, APIM, and infrastructure tags. It triggers when a push is made to the infrastructure branch and runs only when the infrastructure.yml file within the .github/workflows directory is modified.
+The action defines several environment variables for the product, environment, target, and timezone. It configures the Azure CLI defaults, logs in to Azure, and creates a resource group, container registry, virtual network, and container app environment.
+It then sets IP restrictions and configures the APIM system by creating a product and importing an API. The product is named apim-{product}-mdm, and the imported API has the display name MDM with the path /mdm. The API is imported from a container app environment that was created earlier.
 The action has three steps: setup, base, ca, and apim. The setup step sets up infrastructure variables, and each of the next three steps executes a set of specific commands that create the infrastructure, configure the container app, and configure the APIM system.
 
 ## Deployment
 
 ### Script
+
 #### CICD 📝
 
 This Bash script represents a Continuous Integration and Continuous Deployment (CICD) process.
@@ -63,7 +65,6 @@ If both `destination` and `branch` variables are not empty, the script performs
 - Deletes the new branch.
 - Prints a success message indicating the deployment initiation and the switch to the original `branch`.
 
-
 ### Workflow: Deployment 🚀
 
 This workflow is triggered on push events to the `dev`, `staging`, and `production` branches, and specific file modifications.
@@ -109,20 +110,24 @@ This workflow is triggered on push events to the `dev`, `staging`, and `producti
   8. Import ⬇️: Imports an API specification to an Azure API Management (APIM) service.
 
 ## SCA
-This is a GitHub Action YAML file that sets up environment variables and performs various source code analysis (SCA) tasks on the MDM-API project when a pull request is made to the main branch. The code quality SCA is performed by Codacy and the licensing SCA is performed by Fossa. 
-The first job, "setup," sets the environment variables and outputs them for use in later jobs. The next two jobs, "codacy" and "license," run on the "ubuntu-latest" operating system and are triggered by the "setup" job's completion. 
-The "codacy" job uses the Codacy analysis CLI action to perform SCA for code quality. Similarly, the "license" job uses the Fossa action to perform SCA for licensing. 
+
+This is a GitHub Action YAML file that sets up environment variables and performs various source code analysis (SCA) tasks on the MDM-API project when a pull request is made to the main branch. The code quality SCA is performed by Codacy and the licensing SCA is performed by Fossa.
+The first job, "setup," sets the environment variables and outputs them for use in later jobs. The next two jobs, "codacy" and "license," run on the "ubuntu-latest" operating system and are triggered by the "setup" job's completion.
+The "codacy" job uses the Codacy analysis CLI action to perform SCA for code quality. Similarly, the "license" job uses the Fossa action to perform SCA for licensing.
 Secrets, such as the Fossa API key, are assumed to be set up beforehand in the repository's secrets.
 
 ## TEST
-This is a GitHub Actions YAML file that is responsible for initiating unit tests (Jest) and API tests (Jest) upon a pull request (PR) creation on the main branch. 
+
+This is a GitHub Actions YAML file that is responsible for initiating unit tests (Jest) and API tests (Jest) upon a pull request (PR) creation on the main branch.
 The first job, "setup," sets environment variables for the dev environment, a London timezone, and Node.js version 18. It also outputs these variables for later jobs to use.
 The second job, "unit-tests," runs on the ubuntu-latest operating system and executes the unit tests. It uses the output from the "setup" job to set the environment name and timezone, checks out the repository, sets up Node.js, installs dependencies using npm ci, and executes the unit tests using npm run unit-test.
 
 ## Lint
+
 This code is a GitHub Actions YAML file that is responsible for initiating linting checks upon a pull request (PR) creation on the main branch for a Node.js project. The on event is set to pull_request with specified branches and paths. The file has two jobs; "setup" and "lint". The "setup" job sets environment variables for the dev environment, a London timezone, and Node.js version 18, then output these variables for later jobs to use. The "lint" job runs on the ubuntu-latest operating system, sets up the environment name and timezone using the output from the "setup" job, checks out the repository, sets up Node.js, installs dependencies, and executes the linting using npm run lint.
 
 ## Publish
-This is a GitHub Actions YAML file that automates the process of releasing an updated package for a Node.js project. The event that triggers this script is when the main branch is pushed to. There is only one job in this file, which sets up the necessary components for a successful release. This job is called "release", runs on the ubuntu-latest operating system, and uses the "google-github-actions/release-please-action@v3" GitHub Action for automating the release. 
+
+This is a GitHub Actions YAML file that automates the process of releasing an updated package for a Node.js project. The event that triggers this script is when the main branch is pushed to. There is only one job in this file, which sets up the necessary components for a successful release. This job is called "release", runs on the ubuntu-latest operating system, and uses the "google-github-actions/release-please-action@v3" GitHub Action for automating the release.
 
 The "release" job consists of three steps. The first step, "New release" sets up the release parameters and uses the Google GitHub Actions Release Please Action to create a new release. In the "with" block, the release type is set to "node", and the package name is set to "uk-export-finance/mdm-api". There are also four changelog types defined in this step: "feat", "fix", "chore", and "docs". These define the types of changes that will be written to the CHANGELOG.md file. Finally, there is a list of extra files that will be included in the release, which include README.md and CHANGELOG.md.

.github/workflows/deployment.yml

@@ -4,7 +4,6 @@
 # Standard Azure naming convention has been followed:
 # https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/resource-naming
 #
-#
 # Following Azure services are consumed:
 # 1. Azure resource group - https://learn.microsoft.com/en-us/cli/azure/group?view=azure-cli-latest#az-group-create
 # 2. Azure container registry - https://learn.microsoft.com/en-us/cli/azure/acr?view=azure-cli-latest#az-acr-create

README.md

@@ -1,4 +1,5 @@
 # Master Database Management 🚀
+
 MDM micro-service provides endpoints for internal UKEF applications ranging from counties, currencies, yield rates, interest rates to premium schedule.
 
 ## Install 💻
@@ -30,9 +31,9 @@ $ npm run start:dev
 
 We are running several test suites as part of our CI/CD pipeline.
 
-* Unit test :   These tests are written using Jest and ends with `*.test.ts` extension.
-* API test  :   These tests are written using Jest and ends with `*.api-test.ts` extension.
-* E2E test  :   These tests are written using Cypress and ends with `*.spec.ts` extension. Currently there are *no* E2E tests and none are executed during CI/CD.
+- Unit test : These tests are written using Jest and ends with `*.test.ts` extension.
+- API test : These tests are written using Jest and ends with `*.api-test.ts` extension.
+- E2E test : These tests are written using Cypress and ends with `*.spec.ts` extension. Currently there are _no_ E2E tests and none are executed during CI/CD.
 
 ```bash
 # unit tests
@@ -44,51 +45,58 @@ $ npm run api-test
 # api tests with nock debugging (very useful if tests are failing)
 $ DEBUG=nock.* npm run api-test
 ```
+
 ## Docker 📦
+
 ### 1. Dockerfile
+
 Dockerfile is used to build and run a Node.js application in a containerized environment.
 
 #### Stage 1: `Build`
+
 It specifies the base image as `node:19.9-alpine3.16`, which is a minimalistic image of Node.js 19.9 running on Alpine Linux 3.16. The RUN command installs bash and curl packages, then deletes the cache to reduce the image size.
 
 The `WORKDIR` command sets the working directory to `/app`. The `COPY` command copies package.json and package-lock.json to the /app directory, followed by the npm ci command, which installs the dependencies listed in package.json while ensuring compatibility with peer dependencies.
 The COPY command copies the rest of the files in the current directory to the /app directory. The `npm run build` command builds the application.
 Finally, the npm ci command installs **only** the dependencies listed in `package.json`, ignoring the `devDependencies`, thus reducing the final build image size.
 
-
 #### Stage 2: `Production`
+
 This section sets up the production stage of the Dockerfile. It specifies the same base image as the build stage. The `WORKDIR` command sets the working directory to `/app`.
 The `COPY` command copies package.json, package-lock.json, node_modules/, and dist/ directories only from the build stage to the /app directory (production stage).
 Finally, the `USER` command switches the user to the node user, and the CMD command runs the npm `run start:prod` command to start the application in production mode.
 
 #### Conclusion
+
 Overall, the Dockerfile sets up a secure build and deployment environment for the Node.js application, with a non-root user and a lean production image containing only the necessary dependencies and files.
 
 ### 2. docker-compose.yml
+
 This is a Docker Compose file used to define and configure the `api` service.
 
 The first section defines the version of the Compose file syntax being used (version `3.8`), and the services that will be run.
 
 Under the api **service**, the following options are specified:
 
-* `build`: specifies the build context for the Docker image. In this case, it is set to the current directory (.), which means that Docker will look for a Dockerfile in the current directory to build the image.
-* `image`: specifies the name of the Docker image that will be built.
-* `container_name`: specifies the name of the Docker container that will be created from the image.
-* `restart`: specifies that the container should always be restarted if it stops running.
-* `command`: specifies the command that should be run when the container starts. In this case, it is set to `npm run start:prod`.
-* `ports`: specifies the ports that should be exposed by the container. In this case, it is set to ${PORT}:${PORT}, which means that the value of the PORT environment variable will be used for both the host and container ports.
-* `volumes`: specifies any directories or files that should be mounted as volumes inside the container. In this case, it is set to `./:/app/src:rw`, which means that the current directory on the host machine will be mounted as a **read-write** volume at `/app/src` inside the container.
-* `environment`: specifies any environment variables that should be set inside the container. In this case, a list of environment variables is provided, but their values are not specified in the file since they will be referred from local `.env` file. (Please refer to `.env.sample` for getting started).
+- `build`: specifies the build context for the Docker image. In this case, it is set to the current directory (.), which means that Docker will look for a Dockerfile in the current directory to build the image.
+- `image`: specifies the name of the Docker image that will be built.
+- `container_name`: specifies the name of the Docker container that will be created from the image.
+- `restart`: specifies that the container should always be restarted if it stops running.
+- `command`: specifies the command that should be run when the container starts. In this case, it is set to `npm run start:prod`.
+- `ports`: specifies the ports that should be exposed by the container. In this case, it is set to ${PORT}:${PORT}, which means that the value of the PORT environment variable will be used for both the host and container ports.
+- `volumes`: specifies any directories or files that should be mounted as volumes inside the container. In this case, it is set to `./:/app/src:rw`, which means that the current directory on the host machine will be mounted as a **read-write** volume at `/app/src` inside the container.
+- `environment`: specifies any environment variables that should be set inside the container. In this case, a list of environment variables is provided, but their values are not specified in the file since they will be referred from local `.env` file. (Please refer to `.env.sample` for getting started).
 
 The next section defines a **healthcheck** for the container, which will periodically check if the container is running correctly. The options specified are:
 
-* `test`: specifies the command that should be run to test the health of the container. In this case, it is set to `['CMD', 'curl', '-f', 'http://localhost:${PORT}']`, which means that the healthcheck will run the curl command to make a request to the container's web server and check if it receives a response.
-* `retries`: specifies the number of times that the healthcheck should be retried before considering the container as unhealthy.
-* `interval`: specifies the interval at which the healthcheck should be run.
-* `timeout`: specifies the maximum amount of time that the healthcheck command can run before being considered as failed.
-* `start_period`: specifies the amount of time to wait before running the first healthcheck after the container has started.
+- `test`: specifies the command that should be run to test the health of the container. In this case, it is set to `['CMD', 'curl', '-f', 'http://localhost:${PORT}']`, which means that the healthcheck will run the curl command to make a request to the container's web server and check if it receives a response.
+- `retries`: specifies the number of times that the healthcheck should be retried before considering the container as unhealthy.
+- `interval`: specifies the interval at which the healthcheck should be run.
+- `timeout`: specifies the maximum amount of time that the healthcheck command can run before being considered as failed.
+- `start_period`: specifies the amount of time to wait before running the first healthcheck after the container has started.
 
 ## Code ⌨️
+
 ### Generating new resources
 
 To simplify the generation of new resources, you can use the boilerplate [CRUD](https://docs.nestjs.com/recipes/crud-generator)
@@ -109,10 +117,12 @@ this.logger.log({ id: 'your message here' }, 'context-name');
 ```
 
 ### Authentication
+
 The Master Database Management API requires an API Key in order to access its resources.
 This can be achieved by providing a randomised API Key as an environment variable (`API_KEY`) required for endpoint invocation authentication.
 
 ### Caching
+
 Currently, only the ID token that is used for authenticating our requests to ACBS is cached.
 The lifetime of this cache is controlled by the `ACBS_AUTHENTICATION_ID_TOKEN_CACHE_TTL_IN_MILLISECONDS` environment variable.
 This token has a lifetime of 30 minutes, so it is safe to set this variable to any value between 1 and 180000000.