ajaypratap003 / compliance-frontend

Frontend code for Insights Compliance

compliance-frontend

UI application for Red Hat Insights Compliance.

Running the frontend

This application requires the use of Insights Proxy, which is configured with default routes that proxy a staging environment for services that are not available locally. The frontend itself will run via the webpack-dev-server.

Both can be run either manually and separately or in a container setup.

Both will require to have hostnames like ci.foo.redhat.com resolve to the local host. Insights Proxy provides a script to patch the /etc/hosts file for this purpose.

In containers (recommended)

To run the container setup either Podman or Docker and their compose commands can be used to

  $ cp .env.example .env # Can be used to enable a local backend and other services
  $ podman-compose up # Starts up the insights-proxy and the compliance frontend

This will build the image if it is not yet available locally and run the containers to make the frontend available at https://ci.foo.redhat.com:1337/insights/compliance/

Opening a shell

To run tests or lint your code you might want to run a shell container, this can be done via:

  $ podman-compose up                # Only required if no frontend container is running yet
  $ podman-compose run frontend bash # Opens bash within the container to run tests and other tasks

Running other dependent services locally

To configure the proxy to use local services the .env contains a few LOCAL_ variables that can be uncommented and adjusted.

Running on localhost

To run a insights-proxy follow the preparation steps, to then be able and run the following within this repositories directory.

  $ SPANDX_CONFIG="./config/spandx.config.js" bash $PROXY_PATH/scripts/run.sh

This will start a proxy with proper configuration for this frontend.

The frontend itself can be started with npm run start once all dependencies are install.

  $ npm install   # installs all packages
  $ npm run start # starts webpack bundler and serves the files with webpack dev server

Code Notes

Technology stack

• React
• Patternfly
• Jest & enzyme
• GraphQL (using Apollo)

Code standards

ESlint is configured with standards to follow and can be checked via:

$ npm run lint

The CI pipeline is also setup to validate pull requests.

Components

• Patternfly (based) components should always be preferred
• Prefer functional components and hooks over class components
• The insights-frontend-components package is included to provide components shared across the Insights Platform.
• Insights Chrome which provides header and sidebar, as well as authentication and related functions, which is injected/included via insights-proxy

Inventory Components

Some components are "hot loaded" via Insights Chrome. These are known as "Inventory Components" and are used for systems tables and systems details. The source for these components can be found in insights-frontend-components. With the frontend-components repository resides the inventory-compliance package, which implements wrapper components for these inventory components to add compliance specific behaviour.

File organisation

• Presentational Components: These are components that have no side effects. They may handle state internally, but do not require a store or external data source.

• Smart Components: If a component works with any store or makes requests to an API, they are Smart Components

• store: Contains primarily a reducer and actions for working with the inventory component.

• Utilities: Any part that isn't a component or store, should be put here.

Testing

Tests use jest and enzyme. Each component should have at least on test to verify it still renders correctly with changes. The tests for an component should be in a file referencing the component filename and have .test appended (_COMPONENT_NAME_.test.js).

They run on every PR and can locally be executed with:

$ npm run test

Snapshot testing

Most tests are "snapshot" tests, which verify that current test output matches a snapshot taken before. If these changes are legitimate the snapshots need to be updated with:

$ npm run test -- -u

Updating dependencies

This repository has dependabot configured in order to update (some) packages automatically via a pull request. Occasionally these updates will fail snapshot tests and require to update the snapshots as mentioned in the "Testing" section.

Running Sonarqube

Follow instructions to set up self-signed certs, as described here.

Use the docker image:

podman run -itv $PWD:/usr/src -v $PWD/cacerts:/opt/java/openjdk/lib/security/cacerts --rm --name sonar-scanner-cli -e SONAR_HOST_URL='<sonarqube host>' -e SONAR_LOGIN=<token> sonarsource/sonar-scanner-cli