{"id":23066910,"url":"https://github.com/dvsa/cvs-tsk-update-test-stations","last_synced_at":"2025-08-15T11:33:41.579Z","repository":{"id":37438704,"uuid":"450198665","full_name":"dvsa/cvs-tsk-update-test-stations","owner":"dvsa","description":null,"archived":false,"fork":false,"pushed_at":"2024-10-24T10:14:33.000Z","size":1482,"stargazers_count":2,"open_issues_count":8,"forks_count":3,"subscribers_count":6,"default_branch":"develop","last_synced_at":"2024-10-25T02:40:13.180Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"TypeScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/dvsa.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2022-01-20T17:44:56.000Z","updated_at":"2024-08-20T09:02:39.000Z","dependencies_parsed_at":"2023-09-26T19:13:04.814Z","dependency_job_id":"7c84b904-66f0-44e7-92fb-5095d915d1c8","html_url":"https://github.com/dvsa/cvs-tsk-update-test-stations","commit_stats":null,"previous_names":[],"tags_count":1583,"template":false,"template_full_name":"dvsa/cvs-svc-template","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dvsa%2Fcvs-tsk-update-test-stations","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dvsa%2Fcvs-tsk-update-test-stations/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dvsa%2Fcvs-tsk-update-test-stations/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/dvsa%2Fcvs-tsk-update-test-stations/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/dvsa","download_url":"https://codeload.github.com/dvsa/cvs-tsk-update-test-stations/tar.gz/refs/heads/develop","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":229910956,"owners_count":18143229,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-12-16T05:15:32.233Z","updated_at":"2024-12-16T05:15:32.676Z","avatar_url":"https://github.com/dvsa.png","language":"TypeScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"# cvs-tsk-update-test-stations\n\nAWS Lambda function that updates the list of test stations in the ATF Sites DynamoDB from the master list in Dynamics CE.\n\nDesigned to be invoked by a timer every night to pick up the previous days changes, but can be invoked manually.\n\n## Description\n\nThe function authenticates with Azure AD, and uses the returned token to retrieve the details of test stations that have changed from Dynamics CE using OData. Each updated test station is added to EventBridge as a separate event, and EventBridge is then responsible for invoking the Test Station API to perform the actual update in DynamoDB.\n\nThe test stations are queried on their `modifiedon` property; **by default this is midnight yesterday**, but any valid ISO-formatted date can be passed in.\n\nFor example, to update all test stations that have been modified on or since the 1st of December 2021:\n```json\n{\n  \"detail\": {\n    \"lastModifiedDate\": \"2021-12-01\"\n  }\n}\n```\n\nThe solution design can be found in [Confluence](https://wiki.dvsacloud.uk/display/HVT/Selected+Solution+Detail)\n\n## Dependencies\n\nThe project runs on node 18.x with typescript. For further details about project dependencies, please refer to the `package.json` file.\n[nvm](https://github.com/nvm-sh/nvm/blob/master/README.md) is used to managed node versions and configuration explicitly done per project using an `.npmrc` file.\n\n## Running the project\n\nOnce the dependencies are installed (`npm install`), you will be required to rename the `/config/env.example` file to `.env.local` as we use dotenv files for configuration for local local development for example. Further information about [variables](https://www.serverless.com/framework/docs/providers/aws/guide/variables/) and [environment variables](https://www.serverless.com/framework/docs/environment-variables/) with serverless.\nPlease note that multiple `.env` files can be created per environments. Our current development environment is 'local'.\n\nThe application runs on port `:3001` by default when no stage is provided.\n\nThe service has local environmental variables (please see `env` placeholder file) set locally however should we wish to further extend the service, the environmental variables will need to be ported over to the CI/CD pipeline which currently uses `BRANCH` and `BUCKET`.\n\n### Environments\n\nWe use `NODE_ENV` environment variable to set multi-stage builds (region, stages) with the help of dotenv through npm scripts to load the relevant `.env.\u003cNODE_ENV\u003e` file from `./config` folder into the `serverless.yml` file as we don't rely on serverless for deployment.\nIf no `NODE_ENV` value is provided when running the scripts, it will default its `NODE_ENV` value to 'development' with the `.env.development` config file.\n\nThe defaulted values for 'stage' and 'region' are `'local'`. Please refer to the values provided in the `serverless.yml` file.\n\nThe following values can be provided when running the scripts with `NODE_ENV`:\n\n```ts\n// ./config/.env.\u003cNODE_ENV\u003e files\n'local'; // used for local development\n'development'; // used development staging should we wish to require external services\n'test'; // used during test scripts where local services, mocks can be used in conjonction\n```\n\n```ts\n/** Running serverless offline as an example for a specific stage - 'local'.\n* Stage 'local' will be injected in the serverless.yml\n**/\nNODE_ENV=local serverless offline\n\n```\n\nFurther details about environment setup can be found in the provided documentation and `env.example` file.\n\nAll secrets the secrets are will stored in `AWS Secrets Manager`.\n\n### Scripts\n\nThe following scripts are available, for further information please refer to the project `package.json` file:\n\n- \u003cb\u003estart\u003c/b\u003e: `npm start` - _launch serverless offline service_\n- \u003cb\u003edev\u003c/b\u003e: `npm run dev` - _run in parallel the service and unit tests in_ `--watch` _mode with live reload_.\n- \u003cb\u003etest\u003c/b\u003e: `npm run test` - _execute the unit test suite_\n- \u003cb\u003ebuild\u003c/b\u003e: `npm run build` - _bundle the project for production_\n- \u003cb\u003eproduction build\u003c/b\u003e: `npm run build:production` - _generate the project with bundled libraries, minified, concatenated code_\n\n### Offline\n\nServerless-offline is used to run the project locally. Please use `npm run dev` script to do so. Go to `http://localhost:3001/local/version` to confirm that everything has loaded correctly, you should see that the version is the same as the version in the `package.json`\n\nThe below routes are available as default routes from this scaffolding\n\n```\n(GET) http://localhost:3009/local-stage/version\n(GET) http://localhost:3009/local-stage/*/service-name/\n(POST) http://localhost:3009/local-stage/*/service-name/:id/something\n```\n\n### Lambda locally\n\nServerless can invoke lambda functions locally which provide a close experience to the real service if you decide not use the offline mode. `events` and `paths` can be found under `/local` folder.\nFor further details using lambda locally please refer to the [serverless documentation](https://www.serverless.com/framework/docs/providers/aws/cli-reference/invoke-local/).\n\n### Debugging\n\nExisting configuration to debug the running service has been made available for vscode, please refer to `.vscode/launch.json` file. Serverless offline will be available on port `:4000`. 2 jest configurations are also provided which will allow to run a test or multiple tests.\nShould you wish to change the ports when debugging, please change the config args accordingly.\n\nFor further information about debugging, please refer to the following documentation:\n\n- [Run-a-function-locally-on-source-changes](https://github.com/serverless-heaven/serverless-webpack#run-a-function-locally-on-source-changes)\n\n- [VSCode debugging](https://github.com/serverless-heaven/serverless-webpack#vscode-debugging)\n\n- [Debug process section](https://www.serverless.com/plugins/serverless-offline#usage-with-webpack)\n\n## Testing\n\n### Unit\n\nJest is used for unit testing.\nPlease refer to the [Jest documentation](https://jestjs.io/docs/en/getting-started) for further details.\n\n### Release\n\nReleases (tag, release notes, changelog, github release, assets) are automatically managed by [semantic-release](https://semantic-release.gitbook.io/semantic-release/) and when pushing (or merging) to `develop` branch which is protected. [semver](https://semver.org/) convention is followed.\n\nPlease be familiar with conventional commit as described in the Contributing section below.\n\nDefault preset used is angular for conventional commits, please see the [angular conventions](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional#type-enum).\n\nThe `\u003ctype\u003e` `'breaking'` in the commit message will trigger a major version bump as well as any of the following text contained in the commit body: `\"BREAKING CHANGE\", \"BREAKING CHANGES\", \"BREAKING_CHANGES\", \"BREAKING\", \"BREAKING_CHANGE\"`. Please refer to the `.releaserc.json` file for the full configuration.\n\nThe script `npm run release` will automatically trigger the release in CI. To manually test the release the following flags -`--dry-run --no-ci` - can be passed to the release script.\n\nPublishing and artifacts are managed separately by the pipeline.\n\n## Contributing\n\nTo facilitate the standardisation of the code, a few helpers and tools have been adopted for this repository.\n\n### External dependencies\n\nThe projects has multiple hooks configured using [husky](https://github.com/typicode/husky#readme) which will execute the following scripts: `audit`, `lint`, `build`, `test` and format your code with [eslint](https://github.com/typescript-eslint/typescript-eslint#readme) and [prettier](https://github.com/prettier/prettier).\n\nYou will be required to install [git-secrets](https://github.com/awslabs/git-secrets) (_brew approach is recommended_) and DVSA [repo-security-scanner](https://github.com/UKHomeOffice/repo-security-scanner) that runs against your git log history to find accidentally committed passwords or private keys.\n\nWe follow the [conventional commit format](https://www.conventionalcommits.org/en/v1.0.0/) when we commit code to the repository and follow the [angular convention](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional#type-enum).\n\nThe type is mandatory and must be all lowercase.\nThe scope of your commit remain is also mandatory, it must include your ticket number and be all lowercase. The format for the ticket number can be set in the `commitlint.config.js` file.\n\n```js\n// Please see /commitlint.config.js for customised format\n\ntype(scope?): subject\n\n// examples\n'chore(cb2-1234): my commit msg' // pass\n'CHORE(cb2-1234): my commit msg' // will fail\n\n```\n\n### Code standards\n\n#### Code structure\n\nDomain Drive Design diagram with Interfaces, Application, Domain layers and Infrastructure across the layers.\n\n\u003cp align=\"center\"\u003e\n  \u003cimg src=\"./docs/DDD_architecture.jpg\" alt=\"Domain Drive Design diagram with Interfaces, Application, Domain layers and Infrastructure across the layers\" \u003e\n\u003c/p\u003e\n\n#### Toolings\n\nThe code uses [eslint](https://eslint.org/docs/user-guide/getting-started), [typescript clean code standards](https://github.com/labs42io/clean-code-typescript) as well as [SonarQube for static analysis](https://docs.sonarqube.org/latest/).\nSonarQube is available locally, please follow the instructions below if you wish to run the service locally (docker is the preferred approach):\n\n- _Docker_:\n  - Run `docker run -d -p 9000:9000 --name sonarqube sonarqube:latest`\n  - The SonarQube container won't start automatically with your PC. To start it run `docker start sonarqube`\n  - Login with admin/admin - http://localhost:9000 and create a Project with name and key found in `./sonar-project.properties`. There you'll also find instructions for creating and configuring an authentication token.\n  - Run the analysis with `npm run sonar-scanner`\n\n- _Brew_:\n  - Install SonarQube using brew\n  - Change `sonar.host.url` to point to localhost, by default, sonar runs on `http://localhost:9000`\n  - run the sonar server `sonar start`, then perform your analysis `npm run sonar-scanner`\n\n- _Manual_:\n  - Add sonar-scanner in environment variables in your \\_profile file add the line: `export PATH=\u003cPATH_TO_SONAR_SCANNER\u003e/sonar-scanner-3.3.0.1492-macosx/bin:$PATH`\n  - Start the SonarQube server: `cd \u003cPATH_TO_SONARQUBE_SERVER\u003e/bin/macosx-universal-64 ./sonar.sh start`\n  - In the microservice folder run the command: `npm run sonar-scanner`\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdvsa%2Fcvs-tsk-update-test-stations","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fdvsa%2Fcvs-tsk-update-test-stations","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdvsa%2Fcvs-tsk-update-test-stations/lists"}