stolostron / grc-ui Goto Github PK

View Code? Open in Web Editor NEW

0.0 22.0 18.0 71.49 MB

License: Apache License 2.0

JavaScript 94.94% Dockerfile 0.04% Makefile 0.06% Shell 2.27% SCSS 2.51% Handlebars 0.18%

grc-ui's Introduction

grc-ui

Deprecation Notice

The GRC UI is consolidated into the console repository starting in RHACM 2.5.

Description

The UI microservice, grc-ui, is the governance and risk dashboard for Red Hat Advanced Cluster Management. (See grc-ui-api for the API Server microservice it uses)

Design

The UI Platform is developed as an isomorphic React application. View the list of major components that are used to build this service:

NodeJS
Express
React
Handlebars
Redux
Webpack
Babel
Apollo/GraphQL
RedHat PatternFly
Jest
Nightwatch

Build

Install the modules
```
npm install
```

Build the project

   npm run build
or npm run build:watch
or npm run build:production

Run installation

SECURITY WARNING: The GRC UI provides an SSL certificate in /sslcert that is open to the public. In order to run this in production, you'll need to replace these certificates. For our production builds, we replace these certificates using its Helm chart.

Setup environment You need:
- to be connected to a OpenShift 4.x.x cluster
- to have Advanced Cluster Management installed on the cluster
- Run one of the following commands:
```
npm run setup
OR
./setup-env.sh
```
This will create a .env file in the main directory containing the environment variables. You can run source .env to set the variables for use.

The SERVICEACCT_TOKEN expires so if you need to get a new one:
- From the UI...
  - Go to the RHACM Hub, enter the Hub login info, and hit “configure client” from the menu in the top right
- With the CLI...
  - Login to the RHACM Hub with oc using the API Server URL and run
```
oc whoami -t
```
Note: If you want to develop against both the grc-ui & the grc-ui-api you can start the API server and configure the grc-ui to query against the local grc-ui-api server. If you have already sourced the .env file you can run unset grcUiApiUrl to revert to using the default localhost url for communication with grc-ui-api. See the following on how to setup the api server: grc-ui-api.
Start the server for production by running the following command:
```
npm run start:production
```
Start the server for development by running the following commands:
```
npm run build:watch
npm run start
```

5.Open a browser to https://localhost:3000/multicloud/policies and log in using your cluster admin credentials.

Testing

Unit Tests

Run the following command to start all unit tests (run through Jest):

npm run test:unit

Cypress Tests

Note: It is required that the UI runs locally or can target a remote cluster to start the selenium based tests.

Before you run any cypress test, make sure the following envs are set.

export OC_HUB_CLUSTER_URL=    # API URL for remote hub cluster
export OC_CLUSTER_USER=       # User with which to log into the hub cluster
export OC_HUB_CLUSTER_PASS=   # Password for user to authenticate to hub cluster
export OC_IDP=                # Identity Provider to log in with (Use 'kube:admin' for logging in with kubeadmin)

The RBAC tests require a set of users to exist in the remote cluster. To set up these users, first log in to your remote cluster. Decide on a password you'd like to use for these users. Then, from the grc-ui folder, run these commands (the script will also export OC_CLUSTER_USER, OC_HUB_CLUSTER_PASS, and OC_IDP to match the RBAC users and use in place of kubeadmin):

export RBAC_PASS=<your-rbac-password>
source ./build/rbac-setup.sh

For reference, the following users will be created:

USER	ACCESS	ROLE
e2e-cluster-admin-cluster	Cluster	cluster-admin
e2e-admin-cluster	Cluster	admin
e2e-edit-cluster	Cluster	edit
e2e-view-cluster	Cluster	view
e2e-group-cluster	Cluster	view
e2e-cluster-admin-ns	Namespace	cluster-admin for `e2e-rbac-test-1`
e2e-admin-ns	Namespace	admin for `e2e-rbac-test-1` view for `e2e-rbac-test-2`
e2e-edit-ns	Namespace	edit for `e2e-rbac-test-1`
e2e-view-ns	Namespace	view for `e2e-rbac-test-1`
e2e-group-ns	Namespace	view for `e2e-rbac-test-1`

Optional: By default, cypress test runs against a live cluster. You can run cypress test against localhost. Set the environment parameter, CYPRESS_BASE_URL by running the following command:
```
export CYPRESS_BASE_URL=https://localhost:3000
```
Run the following command to start the cypress test:

NOTE: Running npx cypress is not recommended. There is logic in the script called in the npm commands that will customize the test run for your cluster.
- To run the tests with a live browser:
```
npm run test:cypress
```
  NOTE: To open Cypress in an interactive mode and run tests individually, first run export NODE_ENV=debug before starting the headful tests
- To run the tests headless (i.e. with the browser running in the background):
```
npm run test:cypress-headless
```

NPM Commands

View the full list of npm scripts that are described in the following table:

Command	Description
`npm start`	Starts the application with NODE_ENV='development'.
`npm run test:unit`	Runs jest tests.
`npm run test:update-snapshot`	Updates snapshots for jest tests. This command should only be used if you have made changes to a component that requires an updated snapshot artifact for a test case.
`npm run test:cypress`	Runs Cypress e2e tests.
`npm run test:cypress-headless`	Runs Cypress e2e tests with headless browser (i.e. browser runs in the background).
`npm run start:production`	Starts the application with NODE_ENV='production'.
`npm run clean`	Deletes the generated files from public folder.
`npm run build`	Does a FULL development build. (caching disabled and dev source maps)
`npm run build:production`	Does a FULL production build.
`npm run build:watch`	Does a build of application code (w/o the DLL generation) and continues to run in the background watching for changes.
`npm run build:dll`	Only re-builds the the vendor library component.
`npm run lint`	Runs linting on the code base.
`npm run lint:fix`	Attempts to fix any linting errors automatically.

Note: The build process leverages the Dll and DllReference plugins to extract vendor plugins for faster build times and improve browser caching. A separate bundle is created for 3rd-party client-side libraries. The generated bundle is sourced (public/dll.vendor.js) along with its manifest (vendor-manifest.json). If new client dependencies are added or existing versions of dependencies are updated, this module needs to be regenerated and recommitted back into source control. Run the following command npm run build:dll.

Links

These are a few useful links that provide technical reference and best practices when developing for the platform.

grc-ui's People

Contributors

Watchers

Forkers

openshift-cherrypick-robot jnpacker hchenxa yahliu kevinfcormier mark-nc justinkuli dhaiducek zlayne randy424 ycao56 gparvin mprahl asimbutt-redhat chenz4027 robdolares jeswanke vmaroon

grc-ui's Issues

[cypress tests] update template names

In https://github.com/open-cluster-management/grc-ui/pull/365/files template identifiers have been updated to avoid name conflicts. We need to adjust existing config file according to that change. In particular these two files.
https://github.com/open-cluster-management/grc-ui/blob/master/tests/cypress/config/violation-patterns.yaml
https://github.com/open-cluster-management/grc-ui/blob/master/tests/cypress/config/demos/violations.yaml
and function getPolicyTemplatesNameAndKind() from
6405808#diff-7ceaddee365a6d2a38daef17a9cb9504d841b982202b56292a8d4d743b032a12R417

[cypress tests] Existing cypress functions cannot deal with multi-page listing

Functions like verifyPolicyInListing() verifyPolicyNotInListing(), actionPolicyActionInListing(), isPolicyStatusAvailable() and possibly others would work only in case the policy is listed at the first page in the listing. However, in case of multiple policies it may happen that the policy would end up in later page. Therefore we should consider addressing this problem.

One option would be to create a function that (ideally independently on a page) would adjust the listing as follows:

type policy name (or some other text) in the search field to better target listed items
increase the number of listed items to a maximum value
Utilizing such function (or cypress command) in functions mentioned above should effectively help with the described problem.

[cypress tests] function verifyPolicyInPolicyDetailsTemplates() cannot handle different templates

We need to extend verifyPolicyInPolicyDetailsTemplates() function.
This
https://github.com/open-cluster-management/grc-ui/blob/master/tests/cypress/views/policy.js#L413
does work only for the Iam policy. And there could be other policies, even multiple policies. We should probably store relevant templates in a configuration file.. or return it by a function based on policy specifications.

[cypress] add namespace parameter to config/violations-config.yaml

Currently, a 'default' namespace is hardcoded into patterns in config/violations-config.yaml. We should parametrize it, updating getDefaultSubstitutionRules() function to handle this parameter.

[cypress] make the function verifyPolicyDetailsInCluster() generic

In #366 the function verifyPolicyDetailsInCluster() was introduced but before we can use it in tests it needs to be made more generic so it works for various cluster name, policy with multiple specifications and also check the expected violation messages. Please follow the comments in the original PR for more details.

[cypress tests] createPolicy() function in cypress tests does not handle policy update

When using createPolicy() for a policy which already exists, a pop-up window asking whether the policy should be updated appears. We should update createPolicy() to be able to handle this pop-up, most probably by adding a new parameter update=false/true that would drive the behavior.

[cypress] isPolicyStatusAvailable seem to move on even if the status is available only for some clusters

According to this video
https://coreos.slack.com/files/UUGE6M6F9/F01K4PK2WHF/scc_policy_governance.spec.js.mp4
waiting for the policy status has been completed at a moment when only 1 of the 2 clusters had the status available.
Seems that the check in the function is not working well if there are two icons.

Which is weird as there is a condition for having only one <path> element
https://github.com/open-cluster-management/grc-ui/blob/master/tests/cypress/views/policy.js#L227

      cy.wrap(violations).find('path').then((elems) => {
        if (elems.length === 1) {

Unfortunately, this would be difficult to debug without a similar environment.

[cypress] Change the way how function optional parameters are handled

I didn't have much experience with JavaScript / NodeJS when I started working on grc-ui tests. Some things probably were not done the best way. One thing I would suggest is to change how optional parameters in functions are handled.

Currently we are using declarations like
foo = (param1, param2, optional_param1 = value1, optional_param2 = value) =>
which is not very flexible as when an optional parameter is specified all preceding optional parameters needs to be specified too.

Should we switch to a model where we would be using desctructured objects? I.e.
foo = (param1, param2, { optional_param1 = value1, optional_param2 = value2} = {}) =>
where foo would be called like this
foo(1,2, {optional_param2=value2}

Or we could adopt the Cypress model where optional parameters are passed in a dictionary
foo = (param1, param2, options) =>
with foo being called like this
foo(1,2, {'optional_param1': value1})

@ChunxiAlexLuo @ycao56 @dhaiducek @abhiNamdhari What do you think? I am not really an expert in javascript but in some cases having to specify all preceding optional arguments is limiting. Do you have any preferences?

[cypress] improve or remove verifyPolicyInPolicyStatus(), verifyPolicyInPolicyHistory(), verifyPolicyByYAML()

These 3 functions are defined in
https://github.com/open-cluster-management/grc-ui/blob/main/tests/cypress/common/views.js#L742
however they are not really doing anything useful. Some of the functionality is in fact available in different functions/commands.

The only test using these is tests/CertPolicy_governance.spec.js which should be probably updated to use other existing functions/commands.

GVT:One invalid string ID exists in grc-ui/blob/master/nls/platform.properties

In the grc-ui/blob/master/nls/platform.properties, there is one invalid string ID where one space exists between string ID in line: 187.
The invalid string ID is:
overview.top informations.title.count = {0} total violations

Please check it.
Thanks.

[cypress] CertPolicy test missing proper setup/cleanup.

CertPolicy tests expects the policy to be non-compliant, however in Travis the policy is compliant.
This has revealed once we have fixed the respective check. In order not to break the test the respective code has been temporarily (?) disabled again.
See
#388 (comment)

Once the CertPolicy test is fixed, the following code should be enabled
https://github.com/open-cluster-management/grc-ui/blob/master/tests/cypress/views/policy.js#L140

//expect(getStatusIconFillColor(targetStatus)).to.equal(elems[0].getAttribute('fill').trim().toLowerCase())

[cypress] restructure files in the repo

When I started writing Cypress tests I didn't have yet good understanding of GRC features and how the RHACM pages are structured. Originally I wanted to reuse the approach for application-ui repo but it turned out that there are not so many forms to handle while the page tree could be large. Now it seems the the approach used is a bit confusing.

I would propose to restructure files in a repo a bit. For example:

views directory rename to common or even superseded by support
views/policy.js and views/common.js would be merged into one file, e.g. views.js' - here the idea is that views.js` would contain functions used for checking the page content
tests/common/*.js to be merged into a single file and stored e.g. as common/tests.js - here the idea is that tests.js would contain function directly wrapping test steps
tests/demos could be moved or kept.. I do not have an opinion right now, however I would probably store all respective config files under config/demos/*/..

@ChunxiAlexLuo @abhiNamdhari @ycao56 What do you think? What you do/don't like on the current files layout?

[cypress] test the history page

Currently we are not testing pages like /multicloud/policies/all/default/policy-imagemanifestvulnpolicy/status/dhaks1020-2-dho-461/templates/policy-imagemanifestvulnpolicy-image-vulnerability-sub/history. We should create a function for this and add it into a generic test template in https://github.com/open-cluster-management/grc-ui/blob/master/tests/cypress/tests/common/generic_policies_governance.js . Ideally, we would be able to test it after the policy enforcement (if done) and check that both messages (non-compliant and compliant) are listed there.
Please note that the history page is linked both from 'Clusters' and 'Templates' tabs but the target pages seem to be equal. Maybe it would be sufficient to verify the proper link URL in both tabs and the the page content check only once.