Permalink
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
...
- 5 commits
- 48 files changed
- 4 contributors
Commits on Feb 11, 2025
-
chore: Create test db from template (#9265)
## About the changes Based on the first hypothesis from #9264, I decided to find an alternative way of initializing the DB, mainly trying to run migrations only once and removing that from the actual test run. I found in [Postgres template databases](https://www.postgresql.org/docs/current/manage-ag-templatedbs.html) an interesting option in combination with jest global initializer. ### Changes on how we use DBs for testing Previously, we were relying on a single DB with multiple schemas to isolate tests, but each schema was empty and required migrations or custom DB initialization scripts. With this method, we don't need to use different schema names (apparently there's no templating for schemas), and we can use new databases. We can also eliminate custom initialization code. ### Legacy tests This method also highlighted some wrong assumptions in existing tests. One example is the existence of `default` environment, that because of being deprecated is no longer available, but because tests are creating the expected db state manually, they were not updated to match the existing db state. To keep tests running green, I've added a configuration to use the `legacy` test setup (24 tests). By migrating these, we'll speed up tests, but the code of these tests has to be modified, so I leave this for another PR. ## Downsides 1. The template db initialization happens at the beginning of any test, so local development may suffer from slower unit tests. As a workaround we could define an environment variable to disable the db migration 2. Proliferation of test dbs. In ephemeral environments, this is not a problem, but for local development we should clean up from time to time. There's the possibility of cleaning up test dbs using the db name as a pattern: https://github.com/Unleash/unleash/blob/2ed2e1c27418b92e815d06c351504005cf083fd0/scripts/jest-setup.ts#L13-L18 but I didn't want to add this code yet. Opinions? ## Benefits 1. It allows us migrate only once and still get the benefits of having a well known state for tests. 3. It removes some of the custom setup for tests (which in some cases ends up testing something not realistic) 4. It removes the need of testing migrations: https://github.com/Unleash/unleash/blob/main/src/test/e2e/migrator.e2e.test.ts as migrations are run at the start 5. Forces us to keep old tests up to date when we modify our database
-
fix: font size flag change to boolean (#9290)
## About the changes Fix for `uiGlobalFontSize` flag being returned as an object, which is truthy.
-
fix: Use the right theme even if the payload is a variant. (#9292)
Also, use extra css selectors to increase specificity so that this takes precedence over the MUI themes. I don't like that we need to do this weird selector thing, but hey, it is what it is.
Loading
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff v6.7.0...v6.7.1