The TMSS frontend web application was bootstrapped with Create React App.

Import information

Currently the App runs in compatibility mode for React 17. React 18 uses a (even more) asynchronous pattern for set state This breaks some codes who depends on the fact that setstate immedialty is set. CHartjs has been updated recently.

Running TMSS Backend with dependant services in docker

In the local development environment, the docker image of any branch can be downloaded and started with dependent services like rabbitmq to test the TMSS application as a whole.

1. First identify the docker image to be downloaded from the container registry

2. [optional] download the production JSON schemas and replace the path to them in the docker compose

   • Note: if you don't do this, there are only 10 outdated templates available to verify the front-end with
   • Linux users: when mounting the schemas, Linux keeps the SUID of your local system within docker. The user 'lofarsys' with SUID 1 needs to have permission. Solution is to change the SUID of your schemas to '1': sudo chown -R 1000 <your schemas path>

3. Create and run a docker compose with the following to run TMSS and Rabbit MQ with the production schemas.

version: "3"
networks:
  tmss_network:
  default:
    driver: bridge

services:
  rabbitmq:
    image: rabbitmq:latest
    container_name: rabbitmq
    networks:
      - tmss_network

  tmss-backend:
    image: <your docker image>
    environment:
      - RABBITMQ_DEFAULT_USER=guest
      - RABBITMQ_DEFAULT_PASS=guest
      - RABBITMQ_DEFAULT_PORT=5672
      - LOFAR_DEFAULT_BROKER=rabbitmq
      - LOFARENV=TEST
    ports:
      - "8008:8008"
      - "5678:5678"
    volumes:
      - <your schemas path>:/opt/lofar/share/tmss/schemas # overwrite schemas
    command: bash -c 'source /opt/lofar/lofarinit.sh && ALLOWED_HOSTS=* tmss_test_environment -p 8008 -ldmMsSwV --simulate'     #includes legacy
    restart: unless-stopped
    networks:
      - tmss_network

The TMSS backend API can be accessed with url http://localhost:8008/api/ and swagger can be accessed with url http://localhost:8008/api/swagger/

NOTE: This docker container also runs the TMSS Frontend application (http://localhost:8008/).

NPM

requirements

• node version ^14.40.0.

The application is developed, tested and deployed with version 14.20.0. Though it supports all version ^14.20.0, it is not tested yet.

• npm version ^8.3.0.

It is a very outdated version; see 'npm version hell'

npm version hell

Chances are, if you have a recent ubuntu development system, that you have a too recent npm version on your machine. It breaks with the not-so-recent-and-pinnen-at-fixed-version of the TMSS-used-js-modules in package.json. Here's the recipy out of that hell: Use NVM (Node Version Manager). This is a sort of python virtualenv for node. See also: https://github.com/nvm-sh/nvm#readme

cd ~
rm -rf .npm
wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.3/install.sh | bash
echo "lts/fermium" > .nvmrc
nvm install
nvm use
cd <you_lofar_source_tree_root>/SAS/TMSS/frontend/tmss_webapp
npm install
npm start

Available Scripts

Run npm install command to download and install all required modules/packages into node_modules folder.

npm install

When all the dependencies are installed, it is ready to run the application.

In the project directory, you can run:

npm start

Runs the app in the development mode.
Open http://localhost:3000 to view it in the browser.

The page will reload if you make edits.
You will also see any lint errors in the console.

npm run prepareTemplateSchemasDev

Prepares and creates the template schema json files from the latest backend source schemas to run the unit tests locally in development environment with test data. The schema json files are created in build/schemas folder and public/schemas folder. These files are not tracked in the git repository.

npm run prepareTemplateSchemas

Prepares and creates the template schema json files from the latest backend source schemas to run the unit tests in CI/CD pipelines with test data. The schema json files are created in build/schemas folder and public/schemas folder. These files are not tracked in the git repository.

npm run cleanTemplateSchemas

Deletes all schema json files created in build/schemas folder and public.schemas folder.

npm test

Launches the test runner in the interactive watch mode.
See the section about running tests for more information. Note: you need to run the prepareTemplateSchemaDev for local testing and prepareTemplateSchema for testing within docker beforehand

npm build

Builds the app for production to the build folder.
It correctly bundles React in production mode and optimizes the build for the best performance.

The build is minified and the filenames include the hashes.
Your app is ready to be deployed!

See the section about deployment for more information.

npm eject

Note: this is a one-way operation. Once you eject, you can’t go back!

If you aren’t satisfied with the build tool and configuration choices, you can eject at any time. This command will remove the single build dependency from your project.

Instead, it will copy all the configuration files and the transitive dependencies (webpack, Babel, ESLint, etc) right into your project so you have full control over them. All of the commands except eject will still work, but they will point to the copied scripts so you can tweak them. At this point you’re on your own.

You don’t have to ever use eject. The curated feature set is suitable for small and middle deployments, and you shouldn’t feel obligated to use this feature. However we understand that this tool wouldn’t be useful if you couldn’t customize it when you are ready for it.

Available test users credentials

There are four test users available in the backend API which can be used to test the application for different role permission.

Quality checks

Test coverage report

With junit and cobertura, coverage reports are generated within our CI/CD pipeline job integration_test_TMSS_Frontend.

Acces the information via:

• You can see the summary in the 'coverage' column for the jobs.
• You can download the complete reports via the artifacts.
• You can generate the report locally via: npm run test:ci

Sonarcloud check

To test the code for vulnerabilities, code smells, duplication etc. Sonarcube is used within our CI/CD pipeline sonarcloud-check-tmss-frontend.

Access that information in the cloud: sonarcloud

Updating packages

Whenever the CI/CD pipeline fails for the package checks (audit + upgrade), an updater library can be used to easily update it.

You should always do this with care of course since there might be breaking/visual/unwanted changes that are not detected by a test

How to upgrade:

• Quick: npx npm-check-updates -u
• [Recommended] Test mode: npx npm-check-updates --doctor -u
• Check the library for more options: npx npm-check-updates --help

note :

DISABLE_ESLINT_PLUGIN=true ESLINT_NO_DEV_ERRORS=true