Work from another directory¶
Run alis against a service or product without changing your shell's directory, and let the CLI fill in package IDs and references from where it runs.
Prerequisites¶
- A product cloned under
~/alis.build/<org>/build/<product>/(alis clone <org>.<product> --jsondoes this).
Steps¶
-
See what the CLI resolves from a directory:
{"organisation": "acme", "product": "shop", "packageId": "acme.shop.orders.v1", "serviceFolder": "…", "defineFolder": "…", "environments": [{"id": "<env-id>", "displayName": "Development", "production": false, "status": "ACTIVE", "projectId": "<project-id>"}]}--cwdis a global flag: it runs the command in that directory without a shellcdand without changing your parent shell. Coding-agent tools that cannot change directory use it on every call. -
Omit the package ID inside a service folder. These are equivalent:
-
Omit the leading parts of a dot reference inside a product folder. References fill right-aligned:
-
Pass the full reference when you are outside
~/alis.build:
How a package ID maps to folders¶
acme.shop.orders.v1 maps to the implementation folder ~/alis.build/acme/build/shop/orders/v1, the definitions folder ~/alis.build/acme/define/acme/shop/orders/v1, and the service id orders-v1. Multi-segment paths work the same way: acme.shop.internal.api.v2 is internal/api/v2.
Commits are detected too¶
define uses the latest pushed commit of the definitions repo; build uses the latest pushed commit that touched the service folder on the checked-out branch. Push first. In automation, pass --branch <branch> explicitly; a detached checkout must.
Inside a workstation¶
The CLI is locked to the workstation's organisation. A command for another organisation fails with exit 1 rather than resolving elsewhere; alis workstation open <org> opens that organisation's workstations instead.
Related: alis context, Organisations, products and services.