Files
speckle-server/packages/server/modules/cli
Daniel Gak Anagrov 75aa5d9b2d feat(ci): reinstate multiregion tests (#5365)
* feat(multiregion): replace user replication

* chore(multiregion): optimise replication

* maybe it's this

* postgres is fun

* once more

* chore(multiregion): only replicate test user creation during multiregion tests

* feat: improved replicate_query logic

* fix: minor

* fix: starting issue

* feat: included user create and delete specs to multiregion

* feat: removed console logs

* fix: user defaults

* fix: multiregion test helper

* fix: update scenarios for users

* refactor(multiregion): swap replicateQuery concept to asMultiregionOperation (#5301)

feat(multiregion): introduced asMultregionOperator, refactor test to user builder classes

* chore: renamings

* fix: remove comments

* feat: remove user replication

* refactor: simplified spec usages

* chore: comments

* chore: branches and favs

* chore: more tests

* chore: more tests

* fix linting

* fix tests

* feat: dropping replication

* refactor: moved project delete to service

* fix: comment

* feat: updateStreamFactory and updateProjectFacotry

* deleteProjectFactory + replicateFactory

* deleteWorkspaceFactory

* fix: selector

* fix: tests

* fix tests, finished createStreamFactory

* feat: simplify changes

* fix: remove comment

* fix: minor strucutres

* fix: moveProjectToRegion

* fix: moved branch creation outside of multiregion scope

* fix: branch creation

* fix: tests

* fix: ci tests

* fix: removed log form test

* fix: on specs, no random regionKeys

* feat: simplify ci for postgres

* try: fix health check

* feat: fixed tests in ci

* try: entrypoint

* try: entrypoint

* try: entrypoint

* try: POSTGRES_INITDB_ARGS

* feat: apply POSTGRES_INITDB_ARGS to all server tests

* fix: broken test

* fix: reinstate max health attempts

* fix: after merge

* fix: after merge

---------

Co-authored-by: Charles Driesler <chuck@speckle.systems>
2025-09-04 14:49:02 +02:00
..

Using CLI

You can run it like so from the server package's root directory: ./bin/cli (or yarn cli)

Use the --help argument to get more info about each command.

Example for running migrations: yarn cli db migrate latest

Using CLI in test mode (& DB)

Use yarn cli:test to run the CLI in the TEST environment. This will use the test DB and will likely run some code a bit differently than in prod/dev.

Creating new commands

CLI is defined using yargs.We use it to define hierarchical trees of commands which allows for better organization both for command definition and for using the CLI.

All commands are created in the commands directory. Commands should be defined using command modules.

Any top-level modules under commands will be assumed to be command modules. If you want to define a child command for a top-level command, then configure the top-level command to look for further child commands using .commandDir().

Then put those child command modules in a subdirectory that is named after the top level command. So if the top level command is "db", then all of its child commands should be put inside a "db" subfolder.

Example commands dir:

- commands
    - db
        - migrate.js
    - db.js

In this case, db.js is the command module for the top-level db command. And then inside the db folder there's a command module migrate.js for the migrate child command of db.

This results in 2 commands - db and db migrate.