$ loading_
触发 Power Platform 管道部署并跟踪 Power Pages 解决方案发布状态
复制安装指令，让 AI 自动完成配置 · 推荐新手
请帮我安装 askskill 上的 "deploy-pipeline" 技能： 1. 下载 https://raw.githubusercontent.com/microsoft/power-platform-skills/main/plugins/power-pages/skills/deploy-pipeline/SKILL.md 2. 保存为 ~/.claude/skills/deploy-pipeline/SKILL.md 3. 装好后重载技能，告诉我可以用了
请帮我运行 Power Platform pipeline，把 Power Pages 解决方案部署到 staging 环境；先验证包，再应用环境变量与连接引用配置，并持续轮询直到部署完成。
返回已触发的部署任务、目标阶段、验证结果、配置详情，以及最终成功或失败状态。
将当前 Power Pages 解决方案通过 pipeline 推送到 production，使用指定的部署设置，若校验失败请停止并说明原因。
输出生产发布的执行结果，包括是否通过校验、是否开始部署、进度轮询信息和最终状态。
触发一次 Power Platform 管道部署，为目标阶段配置环境变量和 connection references，然后部署并在完成后汇总结果。
给出配置已应用的说明、部署运行记录，以及完成后的状态摘要与异常提示。
Plugin check: Run
node "${CLAUDE_PLUGIN_ROOT}/scripts/check-version.js"— if it outputs a message, show it to the user before proceeding.
Triggers a Power Platform Pipeline deployment run. Reads the existing pipeline configuration from docs/alm/last-pipeline.json, selects a target stage, validates the solution package, and deploys it to the target environment.
Prerequisite: Run
/power-pages:setup-pipelinefirst to create the pipeline configuration.
Refer to
${CLAUDE_PLUGIN_ROOT}/references/cicd-pipeline-patterns.mdfor all HAR-confirmed API patterns used in this skill.
Important: The source (dev) environment must have a Power Platform Pipelines host environment configured. This is set in Power Platform Admin Center (Environments → select env → Pipelines) or via the tenant-level
DefaultCustomPipelinesHostEnvForTenantsetting. Without this configuration,pac pipeline deploywill fail. Thesetup-pipelineskill creates the pipeline definition in the host; this admin step connects the dev environment to that host.
docs/alm/last-pipeline.json exists (created by setup-pipeline).solution-manifest.json existsaz account show succeeds)pac env who succeeds)
plan-almis the front door. When the user expresses an ALM intent (promote / ship / deploy / move to staging / push to prod / release this version), the orchestrator (/power-pages:plan-alm) should run first. Direct invocation ofdeploy-pipelinebypasses the orchestrator's pre-plan completeness check, env-var resolution per stage, activation steps, and validation runs. This gate makes that bypass explicit.
Skip rule. If this skill was invoked as part of an active plan-alm orchestration, skip Phase 0 entirely and proceed to Phase 1. The gate helper exposes this via its inExecution block — pass through silently to Phase 1 when:
inExecution.status === "active"
The helper computes this from docs/.alm-plan-data.json — PLAN_STATUS === "In Execution" AND LAST_INVOCATION_AT within the last 60 minutes. check-alm-plan.js refreshes LAST_INVOCATION_AT automatically on every invocation that finds the plan in execution, so each in-chain skill keeps the chain alive for the next one — even multi-hour deploys (deploy-pipeline alone can take 60 min per stage) survive the window without the chain incorrectly de-classifying. Stalled chains (no heartbeat for > 60 min) reclassify as stale-heartbeat and Phase 0 gates fire normally so an abandoned plan doesn't silently bypass user confirmation.
When inExecution.status is anything other than "active" ("not-running", "stale-heartbeat", "no-plan"), run the Phase 0 gate flow below. Branch on the remaining helper fields:
Step 1 — Run the gate helper.
node "${CLAUDE_PLUGIN_ROOT}/scripts/lib/check-alm-plan.js" \
--projectRoot "." \
--envUrl "{devEnvUrl}" \
--token "{token}" \
--solutionId "{solutionId from .solution-manifest.json, if available}"
The helper returns JSON with { exists, stale, staleness: { reason, detail }, generatedAt, planStatus, ... }. The freshness check requires env credentials + solutionId; without those the helper does an existence-only check.
Step 2 — Branch on the result.
| Result | Behavior |
|---|---|
deferred: true | The user has explicitly deferred ALM for this project (.alm-deferred marker present). Pass through silently to Phase 1 — do not nag. |
exists: false | The user hasn't run plan-alm yet. See Step 3. |
exists: true, stale: false | Plan is current. Pass through silently to Phase 1. |
exists: true, stale: true (reason: solution-modified) | The solution changed after the plan was generated. See Step 4. |
Step 3 — No plan. Tell the user:
…
为 Power Apps 代码应用接入 Azure DevOps 连接器，便于查询工单、提报缺陷与管理流水线。
帮助用户将 Power Apps 代码应用构建并部署到 Power Platform。