/lhm-sch-deploy

name: lhm-sch-deploy
description: LHM schedule migration deployment (write → DataWorks): trigger deployment, poll progress, fetch results, and generate reports. Completes end-to-end deployment through three LHM APIs (SubmitStart to trigger → SubmitInstanceList to poll until ALL_SUCCESS → TaskWriterWorkflowList to fetch per-workflow results), and outputs structured JSON + Markdown reports. Use when the user mentions "部署", "deploy", "提交到 DataWorks" (submit to DataWorks), "发布工作流" (publish workflows), "触发 LHM 部署" (trigger LHM deployment), "查看部署状态" (check deployment status), "deploy 阶段" (deploy stage), or "部署报告" (deployment report). Not applicable to: the schedule exploration/conversion stages (use lhm-scheduler-cli), SQL conversion (use sql-trans), or DDL migration (use ddl-trans). Known limitations: depends on the LHM platform APIs and does not support offline deployment; result-package download (write_verify_report) is not yet integrated — currently only workflow-level results are obtained via the API.

LHM Schedule Migration Deployment Skill

This skill triggers and monitors LHM schedule migration deployment tasks, automatically polls until deployment completes, and generates detailed deployment reports.

Prerequisites

**The environment and credentials have already been prepared by [lhm-sch-env](../lhm-sch-env/SKILL.md) at session start; this skill performs no environment validation whatsoever.** Simply run the deployment command — do not run validation scripts, do not re-confirm credentials, and do not prompt the user about configuration.

> ⛔ **The one exception — the `aliyun-cli-lhm` plugin (hard stop)**: the deployment command reaches the service through `aliyun lhm <command>`, so the plugin (>= 0.1.1, i.e. `~/.aliyun/plugins/aliyun-cli-lhm/manifest.json` exists) must be present. If it is not, **stop immediately**: report the environment error verbatim and terminate. Do **not** prompt the user for a deployment parameter, do **not** run `uv tool install` or `lhm-sch-deploy` — this CLI shells out to `aliyun lhm`, so a successful install is never proof that the flow can proceed — and never report a deployment or upload result that did not come from a real call.

Only when a command actually reports an environment-class error should it be handed to [lhm-sch-env](../lhm-sch-env/SKILL.md).

For reference: credentials are resolved by the aliyun CLI default credential chain (`aliyun configure` / environment variables / RAM Role / `~/.alibabacloud/credentials`) at call time — this skill neither reads nor stores any AK/SK, and the startup banner no longer prints a credential source. The CLI is installed as a uv global tool: `bash install.sh` to install, `bash uninstall.sh` to uninstall.

Usage

Basic Usage

lhm-sch-deploy --task-id <YOUR_TASK_ID>

Full Parameters

lhm-sch-deploy \
  --task-id <TASK_ID> \
  --config config/deploy_config.json \
  --output-dir <session dir>/output/deploy/result \
  --endpoint lhm-pre.cn-hangzhou.aliyuncs.com \
  --region cn-hangzhou \
  --poll-interval 15 \
  --timeout 1800

Parameter Descriptions

| Parameter | Description | Default | |-----------|-------------|---------| | `--task-id` | Migration task ID (optional; when missing, resolved in order from session config / environment variable / config file) | - | | `--config` | Config file path (relative to the current working directory) | `config/deploy_config.json` | | `--output-dir` | Output directory | `<session dir>/output/deploy/result/<timestamp>/` | | `--endpoint` | LHM service endpoint, attached to every `aliyun lhm` call as a fixed parameter (resolved in order: session config `lhm.endpoint` > config file `lhm.endpoint` > `LHM_ENDPOINT` environment variable > default) | `lhm-pre.cn-hangzhou.aliyuncs.com` | | `--region` | Region, attached to every `aliyun lhm` call as a fixed parameter (resolved in order: session config `lhm.region_id` > config file `lhm.region_id` > `REGION_ID` environment variable > default) | `cn-hangzhou` | | `--poll-interval` | Polling interval (seconds) | 15 | | `--timeout` | Timeout (seconds) | 1800 | | `--skip-start` | Skip the trigger step and poll the existing instance directly | false |

Output Directory Structure

The CLI is installed as a global tool with the code directory separated from the runtime directory. By default it outputs to `<session dir>/output/deploy/result/<timestamp>/` under the **session temp directory** (same root as the session config `session.json`). The session temp directory (abbreviated `<session dir>` below) is a per-session dedicated `/tmp/lhm-sch-session-<uid>/s-<timestamp>-<random>/`, which the CLI locates automatically via the pointer file `current` (or `$LHM_SESSION_FILE`):

<session dir>/output/deploy/result/20260115_143022/
├── deploy_result_summary.json       # structured report data
├── workflow_list.json               # raw workflow list data
├── deploy_report.md                 # detailed Markdown report
├── package.zip                      # raw result package
└── package/                         # extracted result package
    ├── write_verify_report.json     # read-back verification report
    ├── workflow.json                # workflow configuration
    ├── nodeSpec.json               # node specifications
    ├── nodeRelationSpec.json       # node dependencies
    ├── trigger.json                # trigger configuration
    └── script/                     # script files

**Output path precedence**: CLI `--output-dir` > config file `output_dir` > default session temp directory (`<session dir>/output/deploy/result/<timestamp>/`)

Config File

The config file (by default `config/deploy_config.json` in the current working directory; overridable with `--config`) persists commonly used parameters:

{
  "task_id": "your-task-id",
  "lhm": {
    "endpoint": "lhm-pre.cn-hangzhou.aliyuncs.com",
    "region_id": "cn-hangzhou"
  },
  "poll_interval_seconds": 15,
  "timeout_secon