andywaltlova/insights-inventory-frontend

The Insights Inventory Frontend

Insights Inventory Frontend

This is the frontend application for Insights Inventory. It is based on the insights-frontend-starter-app.

First time setup

Quick start

1. Make sure you have Node.js (current LTS) and npm installed.
2. Run script to patch your /etc/hosts.
3. Make sure you are using Red Hat proxy.

Running locally

1. Clone the repository.
2. Install dependencies with npm install.
3. Run development server with npm run start:proxy:beta. See dev.webpack.config.js and package.json (npm scripts) for more options and parameters available.
4. Local version of the app will be available at https://stage.foo.redhat.com:1337/preview/insights/inventory/. If you run with slightly different setup (for example, using production environment), you should still see the generated URL in your terminal, the webpack script output.

Testing your changes

We use Jest with React Testing Library to write unit tests. For larger pieces of code or components, we utilize Cypress. For testing commands shortcuts (like npm run test, npm run test:ct, etc.), take a look at the package.json file which lists available scripts.

Before opening a pull request, you can run npm run verify:local to make sure your changes pass automated tests (Jest and Cypress) and linter (both JS and CSS linters). We also execute husky hooks with every commit to make sure the changes pass basic lint checks.

Commit conventions

In order to keep our commits style consistent and the commits history easy to read, we utilize semantic-release which follows Angular Commit Message Conventions. Also, there is a commitlint check run on all branches which ensures that all the commits meet the expected format (<type>(<scope>): <short summary>). Following this standard and specifying at least the type and summary for each commit helps to automatically generate a changelog of changes.

Testing federated modules with another application

If you want to test federated modules (such as InventoryTable or SystemDetail) in another application, you can utilise LOCAL_APPS environment variable and deploy the needed application on separate ports. To learn more about the variable, see https://github.com/RedHatInsights/frontend-components/tree/master/packages/config#running-multiple-local-frontend-applications.

Example

We'll take for example insights-advisor-frontend.

Open new terminal, navigate to Advisor repository, and run it on a separate port without proxy:

npm run start -- --port=8003

In a separate terminal, run Inventory with proxy enabled and list Advisor:

LOCAL_APPS=advisor:8003~http npm run start:proxy

Mocking Inventory API

This is one of the advanced methods to test frontend locally without waiting for API to have desired endpoints available.

Inventory frontend has support for https://github.com/stoplightio/prism CLI. The CLI reads the OpenAPI schema, spins up a localhost server and serves dynamically generated responses for Inventory API endpoints (/hosts, /groups, etc.).

1. Verify package.json config section for the correct URL to OpenAPI schema (contains remote URL by default).
2. Verify dev.webpack.config.js customProxy settings. There you can specify which endpoints to proxy and modify request/response headers.
3. Run npm run mock-server to start the mock server. The fist output must list the endpoints that are generated by the localhost server.
4. In another terminal, run npm run start:mock or npm run start:mock:beta to start the webpack server either in stage-stable or stabe-beta environment. The scripts set the MOCK variable to true and the customProxy is enabled.

Inventory table and detail

We are serving inventory through federated modules, this means both inventory table and inventory detail is served to you in runtime. No need to install and rebuild when something changes in inventory.

Applications using InventoryTable

These applications import InventoryTable component through federated modules:

• vulnerability-ui
• insights-remediations-frontend
• sed-frontend
• tasks-frontend
• compliance-frontend
• patchman-ui
• malware-detection-frontend
• drift-frontend
• ros-frontend
• insights-advisor-frontend
• edge-frontend

Documentation Links

• Components
  • inventory
    • props table
    • props detail
    • custom fetch function
    • hide filters
    • general info tab
  • inventory_header

Release process change in stage env

We use the new release process in stage environment that uses containers for deplyoment. Containerized Frontends are the new way to build, package and deploy the applications.

Common Problems You Might Encounter

• Some APIs we use require the latest version of their client package in order to enjoy the latest properties they provide. In case you checked the Network tab in the console and had a look at the requiered API call that should contain a property you need to fetch and use, but did not see this property in the list of properties in the Response tab, make sure you have the latest version of the client package that contains this API. To make sure the versions align, Have a look at your package.json file and compare the appropriate client package version (that should have the API you need) with the latest published version on npmjs.com. In case they don't match, update this client package to it's latest version by running this command: npm i @redhat-cloud-services/{name-of-client-package}@latest

Then, re-install the modules by running this command: rm -rf node_modules && npm install

And re-run the application This should solve this issue.

In case these steps did not solve your issue, it is possible that the latest package had not been released yet. Please contact the appropriate team to release the package you are using, and go over the described process of updating the client package version again.