1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
//! `mecha10 build-worker` arguments (LAB-5440/5442/5443/5450).
//!
//! This is the *server-side* half of "build via mecha10 dashboard": the CLI invocation
//! mecha10-api's Kestra dispatch sets as the `command` input of a `mecha10-deploy`
//! build-worker container (`docker/build-worker.Dockerfile`'s `ENTRYPOINT ["mecha10"]`, so
//! whatever this command's args look like is literally what mecha10-api must pass). It is not
//! meant to be run by an end user directly, hence `#[command(hide = true)]` on the `Commands`
//! variant - see `handlers::build_worker` for the full contract.
//!
//! A handful of inputs mecha10-api's Kestra dispatch already carries are deliberately **not**
//! CLI args here: `job_id`, `robot_id`, `api_url`, and the control-plane service `token` are
//! read straight from the `JOB_ID`/`ROBOT_ID`/`CONTROL_PLANE_URL`/`MECHA10_API_KEY` env vars
//! `run-container-job.yml` already injects automatically for every dispatched job, the same
//! vocabulary every other build-worker-style job in that template uses - see
//! `handlers::build_worker::WorkerEnv`. Everything else that varies per build-job becomes an
//! explicit flag below.
//!
//! Invocation shape a `mecha10-api` dispatch must produce:
//! ```text
//! mecha10 build-worker --target-platform <target_platform> --target-arch <target_arch> \
//! [--source-url <source_url> --source-token <source_token>] \
//! [--excluded-dirs <build_source_excluded_dirs>]
//! ```
//! `--source-url`/`--source-token` are only needed for the zip-upload source path; omit both
//! entirely for the GitHub path, where `run-container-job.yml` has already cloned the repo into
//! the working directory before `command` runs.
use Args;