This PR extracts the dialog form that we created for the new project
form into a shared component in the `common` folder.
Most of the code has been lifted and shifted, but there's been some
minor adjustments along the way. The main file is
`frontend/src/component/common/DialogFormTemplate/DialogFormTemplate.tsx`.
Everything else is just cleanup.
This PR attempts to make the feature.spec and segements.spec test suites
more reliable. They have been flaking out a lot recently, and this will
hopefully make them less flaky.
The way of handling it is a little different for each test suite.
## feature.spec
Some of the failures we're seeing for the feature/feauture.spec test
suite are due to uncaught resize observer issues (possibly triggered by
the banners).
We can ignore these errors as they don't impact functionality, only
rendering, and are likely to resolve themselves quickly in real-world
scenarios.
On the other hand, it might also ignore actual errors, so I'm not a 100%
on this. Would love some input.
However, MDN has some info on [observation
errors](https://developer.mozilla.org/en-US/docs/Web/API/ResizeObserver#observation_errors):
> As long as the error event does not fire indefinitely, resize observer
will settle and produce a stable, likely correct, layout. However,
visitors may see a flash of broken layout, as a sequence of changes
expected to happen in a single frame is instead happening over multiple
frames.
Based on that, I think this is a pretty safe error to ignore.
I'm unsure whether catching this exception is only set in the `after`
cleanup or whether it pollutes the cy object for all tests, but I think
it's fine either way. But if you have ideas, I'd love to hear them.
## segments.spec
The issue here appears to be that when we first input the segment's name
in the form, it takes a little time for the UI to become ready, so the
first characters of the string are cut off.
This is a known [issue that the cypress team are
aware](https://github.com/cypress-io/cypress/issues/3817), but that
isn't likely to get fixed any time soon because no one can give them a
reproducible example.
You can see the effect of this on segments that haven't been cleaned up
in the preview:
![image](https://github.com/Unleash/unleash/assets/17786332/1db59906-a2ee-4149-869b-81f2245b4399)
To work around it, we add a 500ms wait before we start filling out the
form. Yes, adding [waits in your tests is an
antipattern](https://docs.cypress.io/guides/references/best-practices#Unnecessary-Waiting),
but it's the easiest way around in this case.
We *could* investigate and find a way not to need that, but that would
likely be a much larger project. This appears to mitigate the issue
immediately, so is at least a pretty good temporary fix in my opinion.
We also already do this in other tests, so there is a precedent for it.
## About the changes
This PR will validate that our current migrations are backward
compatible with the latest stable release of Unleash.
It will do so by starting a database, applying the latest migrations,
and then starting a docker container with the last stable unleash
release and running UI tests against it.
There's a risk that the current version of UI tests will not work with
the previous version of our UI. Because of that we copied the previous
version of cypress tests
(https://github.com/Unleash/unleash/tree/5.6/frontend/cypress) into oss
folder and removed the ones that are enterprise only. We can discuss a
better way of doing this to avoid having to maintain this folder always
in sync with the previous version of Unleash
This action will only run when there are changes in migrations or to
cypress tests.
This PR fixes a race condition between e2e tests where bulk archiving
all toggles in the default project would delete toggles used for the
features e2e tests.
It does by isolating the features.spec and overview.spec to their
respective projects, so that they always operate on isolated data.
### Future enhancements:
I'm not particularly fond of passing the projectName through to all the
helper methods. It complicates the tests more than it should. I would
like to be able to set the project once per test and have all the helper
methods be aware of the context. Something like this should work:
```
before(() => {
cy.wrap('projectId').as('project');
})
```
And in the helpers:
```
export const createFeature_API = (
featureName: string,
options?: Partial<Cypress.RequestOptions>,
): Chainable<any> => {
return cy.get('@project').then((project) => {
projectName = project || 'default';
return cy.request({
url: `${baseUrl}/api/admin/projects/${projectName}/features`,
method: 'POST',
body: {
name: `${featureName}`,
description: 'hello-world',
type: 'release',
impressionData: false,
},
...options,
});
});
};
```
<!-- Thanks for creating a PR! To make it easier for reviewers and
everyone else to understand what your changes relate to, please add some
relevant content to the headings below. Feel free to ignore or delete
sections that you don't think are relevant. Thank you! ❤️ -->
Remove strategy improvements flag
## About the changes
<!-- Describe the changes introduced. What are they and why are they
being introduced? Feel free to also add screenshots or steps to view the
changes if they're visual. -->
<!-- Does it close an issue? Multiple? -->
Closes #
[1-1048](https://linear.app/unleash/issue/1-1048/remove-strategyimprovements-flag)
<!-- (For internal contributors): Does it relate to an issue on public
roadmap? -->
<!--
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#
-->
### Important files
<!-- PRs can contain a lot of changes, but not all changes are equally
important. Where should a reviewer start looking to get an overview of
the changes? Are any files particularly important? -->
## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->
---------
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
This PR revamps e2e tests, while adding a new one for the interactive
demo guide:
- Bumps Cypress from `9.7.0` to `12.11.0`;
- Bumps Cypress GH action from `v2` to `v5`;
- Makes any adjustments needed;
- Fixes a lot of issues identified with existing tests;
- Adds new `demo.spec.ts` e2e test that covers the entire demo guide
flow;
**Note:** Currently does not include `demo.spec.ts` in the GH action, as
it
[fails](https://github.com/Unleash/unleash/actions/runs/4896839575/jobs/8744137231?pr=3656)
on step 2.13 (last step of "user-specific" topic). It runs perfectly
fine locally, though.
Might be placebo, but in general tests seem less flaky now and they may
even be faster (especially when not adding the `demo` one, which would
always take a long time).
Adds proper typescript support.
Created reusable commands
Added README for cypress test
Refactored tests
Fixed bugs as I found them.
<!-- Thanks for creating a PR! To make it easier for reviewers and
everyone else to understand what your changes relate to, please add some
relevant content to the headings below. Feel free to ignore or delete
sections that you don't think are relevant. Thank you! ❤️ -->
## About the changes
<!-- Describe the changes introduced. What are they and why are they
being introduced? Feel free to also add screenshots or steps to view the
changes if they're visual. -->
<!-- Does it close an issue? Multiple? -->
Closes #
<!-- (For internal contributors): Does it relate to an issue on public
roadmap? -->
<!--
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#
-->
### Important files
<!-- PRs can contain a lot of changes, but not all changes are equally
important. Where should a reviewer start looking to get an overview of
the changes? Are any files particularly important? -->
## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->
---------
Signed-off-by: andreas-unleash <andreas@getunleash.ai>