frontend: Stabilization for e2e tests

[gorankokin]

Stabilized e2e Cypress test for Data Pipelines project. No regression are expected, because only tests are changed and some attributes are added/changed in Components html templates.
Tested local build, linking built lib to UI and manual validation for different screen, e2e tests executed headless and headed and seems there is no problems. ESLint executed successfully and there no issues.

• Changes includes mainly propagated e2e tests from SC which were stabilized there, under different initiative (issue).
• With tests propagation there was need to add attributes on some HTML elements and minor changes in Components HTML templates, which shouldn't break anything and are validated manually and with e2e runs locally on my machine.
• There are minor scripts changes and added one env variable test_environment in gitlab variable to adopt backpropagated stabilized tests from SC.
• Improved sidebar menu navigation where Explore and Manage section are not expanded by default and works i sync with URL
• Added root spinner that would show loading state while static files are getting fetch in Browser before application get bootstrapped
• Changed Cypress default timeouts.

Issue: #1769

[DeltaMichael]

Can you please add a short list of the changes you made? It's a bit hard to tell just from the diff.

[ivakoleva]

The recommendation is to split those changes, into separate PRs.
With accordance with our guidelines https://github.com/vmware/versatile-data-kit/wiki/How-to-prepare-a-new-PR#break-your-code-commits-into--small-self-contained-units it is expected to take the necessary time, to have all the changes you may want. Otherwise, you may think you'll speedup multiple changes on the back of one single change needed - however that's a workaround, and shifts the responsibility to the Reviewers, to take enormous efforts trying to understand what all ~100 files changed are about.

[gorankokin]

@ivakoleva I agree with you, but not totally. I don't agree that in this way responsibilities are shifted to reviewers because all of us are working in the best interests of the project and no one is trying to workaround something or push bad code, or not working code in production.
Everything is done in the best interests of the projects and to make easier for all members in the project to develop and contribute in a stable environment.

[ivakoleva]

@ivakoleva I agree with you, but not totally. I don't agree that in this way responsibilities are shifted to reviewers because all of us are working in the best interests of the project and no one is trying to workaround something or push bad code, or not working code in production.
Everything is done in the best interests of the projects and to make easier for all members in the project to develop and contribute in a stable environment.

Hi @gorankokin, please split the critical change out of the cosmetic changes, to speed it up.
The recommendation is, upon each change, to create a PR describing why the change is needed, and what the change is, and how was it tested.

[ivakoleva]

LGTM? May resolve the comments and merge?

[gorankokin]

One thing that I need to mention is that with this PR e2e tests execution time is almost at the limit with ~53mins while the CI/CD job limit is 1h.
Maybe we will need to allocate a specific gitlab runner with increased resources (one more CPU), because execution artefacts (videos, images, hars) compression takes around 15mins.
With increased resources I believe we will go down to 40-45mins, because local execution finish in about 18mins.

[ivakoleva]

LGTM! I think we need to resolve the comments and merge 😊

[ivakoleva]

One thing that I need to mention is that with this PR e2e tests execution time is almost at the limit with ~53mins while the CI/CD job limit is 1h.
Maybe we will need to allocate a specific gitlab runner with increased resources (one more CPU), because execution artefacts (videos, images, hars) compression takes around 15mins.
With increased resources I believe we will go down to 40-45mins, because local execution finish in about 18mins.

That's a good catch, may add a ticket with those observations, so we can prioritise it?

[ivakoleva]

Lets resolve the comments and merge?
Also, are the e2e tests stable lately?