Inventory Frontend

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

Table of contents

• Getting started
  • Quick start
  • Running locally
• Testing
  • Unit testing
  • E2E testing: Playwright
    • Local Setup
    • Running Tests
    • CI Workflows
• Commit conventions
• Testing federated modules with another application
• Mocking Inventory API
• Inventory table and detail
  • Applications using InventoryTable
• Component documentation
• Release process
  • Latest image and Stage deployment
  • Pre-promotion verification
  • Promoting to production
  • Post-release verification
• Common Problems You Might Encounter

Getting started

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. 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/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

Unit testing

• Jest + React Testing Library for unit tests
• Cypress for component tests
• Run npm run verify:local before opening a PR (runs tests + linters)
• Husky hooks run lint checks on every commit

See package.json for all available test scripts (npm run test, npm run test:ct, etc.).

E2E testing: Playwright

E2E tests live in _playwright-tests/. See the Playwright README for detailed test configuration (tags, predefined workspaces, RBAC tests).

Local Setup

1. Create .env from playwright_example.env:

   PLAYWRIGHT_USER=<stage-credentials>
   PLAYWRIGHT_PASSWORD=<stage-credentials>
   STAGE_OFFLINE_TOKEN=<qe-ui-inventory-token>
   PROXY=squid.corp.redhat.com:3128  # if running against stage directly
   BASE_URL=https://stage.foo.redhat.com:1337
   

2. Install the test runner:

   npm install --save-dev @playwright/test

3. Install Playwright browsers and dependencies:

   npx playwright install

   If using any OS other than Fedora/RHEL (i.e., Mac, Ubuntu Linux):

   npx playwright install --with-deps

Running Tests

# Start dev server first
npm run start:stage

# Run tests
npx playwright test                              # all tests
npx playwright test --headed                     # watch in browser
npx playwright test test_navigation.test.ts     # specific file
npx playwright test --grep @rbac                 # by tag
npx playwright test --grep-invert @integration   # exclude tag

# With feature flags
SYSTEMS_VIEW=true npx playwright test
INVENTORY_VIEWS=true npx playwright test

CI Workflows

Every PR runs 3 E2E workflows in parallel:

Workflow	Feature Flag	What it tests
Full Test Suite	SYSTEMS_VIEW=true	Stage-stable (default user experience)
InventoryViews Tests	INVENTORY_VIEWS=true	Stage-preview with InventoryViews feature
Legacy Table Tests	LEGACY_INVENTORY_TABLE=true	Legacy InventoryTable federated module

Why 3 workflows?

1. Full Test Suite — Default experience with SystemsView
2. InventoryViews Tests — Preview environment with upcoming InventoryViews feature
3. Legacy Table Tests — InventoryTable is consumed by ~10 downstream apps (Advisor, Patch, Vulnerability, etc.) and must remain functional

Additional workflows:

• Stage: Daily Frontend Suite — Daily at 04:00 UTC, catches backend regressions
• Prod Post-Release Sanity — Manual trigger after releases

Both notify the #hbi-frontend Slack on failure.

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 first 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
• ros-frontend
• insights-advisor-frontend

Component documentation

The repository contains components covered with the documentation comments using JSDoc markup language. The HTML documentation can be generated with the npm run docs script. Additionally, the documentation is automatically built with the Generate and Release Documentation GitHub action. The deployed documentation is available at https://redhatinsights.github.io/insights-inventory-frontend.

Release process

This section describes the process of getting a code change from a pull request all the way to production.

Latest image and Stage deployment

When a new pull request is opened, some jobs are run automatically, like unit tests, code style tests, E2E playwright tests, etc.

When a pull request is merged to master, a new container image is built and tagged as insights-inventory-frontend:latest. This image is then automatically deployed to the Stage environment.

1. Pre-promotion verification

Verify E2E Test Status

We use Playwright E2E tests triggered via GitHub Actions. Navigate to the Actions tab in GitHub and locate the Stage: Daily Frontend Suite workflow:

• Check latest results: If no PRs have been merged recently, you may verify the latest daily run results.
• Manual run (always recommended):
  • In Stage: Daily Frontend Suite workflow click Run workflow against the master branch.
  • Wait for completion to ensure the latest PR changes haven't introduced regressions.

2. Promoting to production

The Standard Release method uses the app-interface-bot. This is the preferred way to promote the latest validated image from the master branch.

Standard release: Automated

• Navigate to the to Bot Pipelines
• Click New pipeline (top right).
• Configure the following variables:
  • HMS_SERVICE: host-inventory
  • HOST_INVENTORY_FRONTEND: master
  • FORCE: Use --force. This will skip validation of GitHub check runs on the commit. We are not running any tests in these checks and they can fail intermittently, for example because of some unrelated Konflux issue. If any relevant check fails and a new image is not built or pushed to Quay, the app-interface MR checks won't pass and it won't allow us to merge the release MR anyway.
• Click Run Pipeline.
• Result: The bot will create a MR and post the link in the #insights-release Slack channel.

Fallback: Manual promotion

Use this method only if you need a targeted release (e.g., rolling back to a specific SHA or skipping a buggy commit).

• Open MR for deploy-clowder.yml file.
• Update the ref for prod-frontends and prod-multicluster-frontends namespaces

Approval and monitoring

Once the MR is open (either manually or via bot):

• Validation: Review the list of PRs included. Ensure all associated Jira cards are in "Release Pending" (no cards should be "On QA").
• Review: Request a review from another Inventory team member.
• Approval: The reviewer must comment /lgtm to trigger the automatic merge.
• Responsibility: The engineer who approved the MR is responsible for monitoring the rollout to ensure the production environment remains stable:
  • OpenShift namespace: frontends
  • Check for Pod: inventory-frontend

3. Post-release verification

After the changes have successfully landed in Production (verify the deployment is complete, not just merged):

• Trigger Prod Post-Release Sanity workflow.
• Confirm all E2E tests pass against the live production environment.

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.