Skip to Content
Testing快速輔助應用程式部署

快速輔助應用程式部署

該功能的作用

目前的應用程式提示端點將書面摘要與 existing Git template repository 結合,並透過正常的不可變應用程式部署管道對該儲存庫進行排隊。該概要被儲存為以後迭代的出處。

not 會根據摘要產生新的應用程式儲存庫。範本 URL 是必需的,且第一個部署包含已解析修訂版的範本來源,除非該來源已經實作了請求。

根據提示和範本創建

POST /api/apps/from-prompt Content-Type: application/json { "brief": "A private reading-list app with a health endpoint", "template_git_url": "https://github.com/example/reviewed-template.git", "branch": "main", "visibility": "private" }

回應包括持久應用程式、部署和建置 ID 以及建置流程 URL。創建是異步的。遵循部署記錄或建置流程,直到達到最終狀態;不要僅僅因為進展緩慢而提交重複的部署。

提交請求之前:

  • 審查儲存庫及其許可證;
  • 固定或記錄部署使用的確切來源版本;
  • 驗證其安裝、建置、運行、連接埠和運行狀況行為;和
  • 對提示和存儲庫保密。

提示是上下文,而不是結果來源滿足它的證據。根據簡報得出的驗收標準測試部署的行為。

請求稍後更改

POST /api/apps/{app_id}/iterate Content-Type: application/json { "instruction": "Add an authenticated export endpoint and a regression test" }

這將為您擁有且具有 Git 來源的應用程式分派非同步修復代理任務。民意調查:

GET /api/apps/{app_id}/agent-status?thread_id={thread_id}

狀態回應將最新的部署狀態與迭代執行緒狀態以及任何報告的結果證據結合。

重要的迭代邊界

目前的修復路徑可以在其沙箱中工作並請求全新部署,但仍無法保證持久返回開發人員的 Git 儲存庫。因此,done 代理線程本身並不證明:

  • 請求的變更存在於上游儲存庫中;
  • 建立了特定的提交;
  • 測試通過;
  • 新的部署開始生效;或
  • 可以還原舊的部署。

對於每次迭代,獨立記錄上游提交、部署 ID、建置 ID、運行狀況結果和驗收測試證據。如果上游儲存庫未更新,請在依賴變更之前透過操作員審查的原始程式碼控制工作流程保留修補程式。

安全接受順序

  1. 將簡報轉換為可觀察的驗收標準。
  2. 檢查所選模板和確切的修訂版本。
  3. 對一項部署進行排隊並遵循其持久 ID。
  4. 分別確認建置、候選人健康檢查和路由切換。
  5. 針對已部署的 URL 執行驗收標準。
  6. 確認來源提交存在於您控制的儲存庫中。
  7. 保留證據和回滾目標。

有關不可變的部署階段和故障處理,請參閱套用部署