This is the frontend application for Insights Inventory. It is based on the insights-frontend-starter-app.
- Make sure you have
Node.js
(current LTS) andnpm
installed. - Run script to patch your
/etc/hosts
. - Make sure you are using Red Hat proxy.
- Clone the repository.
- Install dependencies with
npm install
. - Run development server with
npm run start:proxy
. Seedev.webpack.config.js
andpackage.json
(npm scripts) for more options and parameters available. - 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.
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.
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.
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.
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
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.).
- Verify package.json
config
section for the correct URL to OpenAPI schema (contains remote URL by default). - Verify dev.webpack.config.js
customProxy
settings. There you can specify which endpoints to proxy and modify request/response headers. - Run
npm run mock-server
to start the mock server. The fist output must list the endpoints that are generated by the localhost server. - In another terminal, run
npm run start:mock
ornpm 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.
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.
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
- edge-frontend
- Components
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.
- 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.