Проект из репозитория
import_repoCreate a Layero project from a repository — path (a) without the dashboard. From then on a push to the branch is a preview, a push to the production branch is production.
After the link the tool finishes the setup wizard itself and starts the
first build; `setup` in the result says whether that happened. Detected
values are NOT written into the project settings: the builder detects
the framework, build command and output folder from the repository on
every build, so a later change in the repository is picked up. Only a
decision is pinned — the app folder of a monorepo and the package
manager named in `layero.json`. Until 2.1.1 the project stayed in
`pending_setup` while the answer promised a build that never started.
Two shapes, same as the CLI: GitHub goes through the App installation
(project and webhook in one call); other providers create the project
first and then connect the source — that step reports whether the
webhook could be registered. If the provider is not connected, the result
says `needs_connection` with the dashboard address: the person connects
the token there, never through the chat.
Monorepo: one project builds one app folder — pass `root_directory`.
Several apps in one repository are several projects, one call each, with
different `root_directory` and `name`. If the repository is already
linked and the call would duplicate an existing project (same folder, or
no `root_directory` given), nothing is created: the result is
`already_linked` with `linked_projects` — slug, url, root_directory and
branch of every project built from this repository. On `created`,
`linked_projects` lists the OTHER projects already built from the same
repository; `linked_projects_checked: true` says the check was made, so
an empty list means there are none (`my_projects(repo=…)` answers the
same question later). When the root has no
app and detection sees a frontend + backend pair, `app_dir_candidates`
names the folders.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Project name; the slug and the address are derived from it. Defaults to the repository name — for a second app from the same monorepo give a distinct name. | |
| repo | Yes | Repository path at the provider: `owner/repo`; GitLab paths may be nested (`group/sub/project`). The form `gitverse:owner/repo` is accepted too. | |
| branch | No | Production branch. Defaults to the repository's default branch. | |
| deploy | No | Finish the setup wizard and start the first build right away. The framework, build command and output folder are not pinned: the builder detects them from the repository on every build (`layero.json` overrides). `false` leaves the project in the setup wizard: no builds until the person completes the setup in the dashboard. | |
| provider | Yes | Provider: github, gitverse, gitlab, gitflic or sourcecraft. | |
| organization | No | Organization slug. Without it — the account's only organization, or the personal one; if there are several and none is personal, the tool lists the slugs. | |
| root_directory | No | Monorepo: the app folder inside the repository, relative to its root — `apps/web`, `frontend`. Omit it for an app in the repository root (if the root has no app and exactly one subfolder does, that folder is picked automatically). A repository already linked to a project can be imported again ONLY with a `root_directory` that no linked project uses. |
Output Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| repo | Yes | ||
| setup | No | ||
| branch | No | ||
| status | Yes | ||
| project | No | ||
| provider | Yes | ||
| setup_url | No | ||
| project_id | No | ||
| connect_url | No | ||
| next_action | Yes | ||
| setup_error | No | ||
| webhook_url | No | ||
| organization | Yes | ||
| webhook_hint | No | ||
| root_directory | No | ||
| first_deploy_id | No | ||
| linked_projects | No | ||
| app_dir_candidates | No | ||
| webhook_registered | No | ||
| linked_projects_checked | No |