npx nx workspace:seed:demo doesn't exist
I'm trying to write automated scenario according to bullet points here but I can't seed my database by running
npx nx workspace:seed:demo (command taken from https://github.com/twentyhq/twenty/discussions/6467), is this command correct?
Logs from --verbose:
21 Replies
Now I kinda debugged it and when I run
yarn command:prod workspace:seed:demo it runs correctly but there still is an error Error: Could not get DEMO_WORKSPACE_IDS. Please specify in .env@ɃØĦɆᵾS if you are contributing you should use nx:
npx nx run twenty-server:command workspace:seed:demo (this will make sure your server is properly built)
If you are self-hosting (everything is pre-built for you) you should use yarn :
yarn comand:prod workspace:seed:demo
this two ways to execute the same command
this command needs DEMO_WORKSPACE_IDS to be set in your env variable. If you are contributing it should be in your .env
DEMO_WORKSPACE_IDS={a_valid_uuid}
If you are self-hosting, it should be in your environment variables directlyOkay, I'll get back once I have some time to test this
thanks @ɃØĦɆᵾS! The tests need you 😄
Also, I have a question, why author of linked discussion uses both yarn and npx?
mmmh good point, as these are dev tasks they should be run using npx nx run
otherwise we can't be sure it's properly built or we can't leverage monorepo caching provided by nx
updated
I'm taking a look to your post on the discussion
Thanks a lot
thank you!
@charles checked and both yarn and npx commands are working now as expected, so all yarn commands should be replaced with npx?
In contributor mode use nx: npx nx run package:command
In production (self-host) mode: use yarn directly (nx should not be used)
Here is the rational:
- while contributing we want to execute commands / build on fresh code. So we are watching files, making sure that they are properly built. As project start to grow, we split it into package and packages start to have dependencies. For instance twenty-front depends on twenty-ui. While working on twenty-front, we need to make sure that twenty-front AND twenty-ui are properly built. This starts being slow and does not scale well. Nx enables us to cache command outputs and do not re-execute them if the source file have not change. It's a mono-repo caching tool
- so while you contribute you should always use nx. In CIs, we also use nx so developer can run tests or other ci commands easily on their machine
- in production mode we don't ship with nx as there is no need to build the project, it's already built in the docker image and you d'ont have any dev tooling. In this case, you have to use yarn commands
Also, to make a clear separation:
- nx commands are located in project.json / nx.json
- yarn commands are located in package.json
Wow, thanks for such detailed answer! 👍
I'll try to create a PR today once I fix some stuff
Also, as I'm working on CI, tests should be performed on localhost or on demo? If localhost, then everything must be built? @charles
I think we should do it on demo
I'm asking because I'm not sure if the instance exists between each workflow or each workflow builds the project independently of others
the tests should be executed from a github action runner but targetting a specific workspace on demo
that would fit our pre-deployment checklist and provide a stable environment that the core team would maintain (we already maintain demo)
Okay, what about running commands like resetting database? Is it possible to run them from runner i.e. does runner have (or will have) access to demo's console?
I think we should not reset demo environment but seeding it with some data looks good. Maybe we could seed a separate workspace like [email protected]. Maybe a few so we can run the tests many times or we could have a mechanism to trigger e2e reseed on demo.twenty.com
I'll try to think of a better solution as the only way to solve this issue coming to my mind is by 2 separate configuration which is rather a bad idea, especially when all options except for the base URL will be the same
@charles I'll take a bit longer than I expected as I'm having some problems with Playwright after rebasing main onto my branch in fork (not sure how nor why)
@charles I finally fixed it but I checked the changes merged in https://github.com/twentyhq/twenty/pull/6539 and these are wrong to say the least as:
1. the test checks if table is visible in Welcome page, not in Companies page (because even though there's
goto('/objects/companies'), tests are run from the fresh setup and user is not logged in) so the whole point of the test is basically misunderstood
2. playwright.config.ts is basically generated template with added imported config from dotenv and setting up baseURL, where there should be some more settings, like e.g. screenshots on failure, fixed viewport (resolution of browser to ensure consistency) and such
3. related to 1, .env contains only base URL which can be set in playwright.config.ts (but that's up to taste) whereas there should be at least some more data e.g. user's login and password
I'm thinking if I can revert this commit or override it completelyGitHub
feat(e2e): twenty-e2e-testing with playwright by Nabhag8848 · Pull ...
ISSUE (e2e) - Introduces e2e for twenty
Closes Setup E2E testing #6360
Description
Create Package.
Setup environments such as baseUrl.
ignore CI configuration for now.
write a simple test to...
Now I found about this issue (https://github.com/twentyhq/twenty/issues/3007), originally where this command was located?
GitHub
Issues · twentyhq/twenty
Building a modern alternative to Salesforce, powered by the community. - Issues · twentyhq/twenty
@charles I managed to create a Github CI for E2E tests, they kinda work (it doesn't throw errors related to wrong command like earlier but to wrong URL as I didn't setup/use a server on runner)
That's great @ɃØĦɆᵾS, we are reviewing your work with Lucas and it seem awesome
I was superbusy with performance issues but I'll also make sure that your E2E tests are well integrated to our workflows and CIs