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?