清單-專案

GET /v1/projects

• 頁面記號查詢參數已從 start 重新命名為 token。
  • 例如，呼叫 list-projects 作業已從 GET /v1/projects?limit=5&start={page_token} 變更為 GET /v1/projects?limit=5&token={page_token}。
• 傳回的第一頁在要求 URL 中沒有記號查詢參數。 例如，GET /v1/projects?limit=5 OR GET /v1/projects。
  • 當指定的頁面記號無效時，也會傳回第一頁。
• 不再支援 last 和 previous 欄位，也不再包含在回應有效負載中。

list-configs

GET /v1/projects/{project_id}/configs

• 此作業現在已分頁。
• 如果未在 limit 查詢參數中指定頁面大小，則會傳回預設值 10 筆記錄。
  • 頁面大小上限為 100 筆記錄。
• 傳回的第一頁在要求 URL 中沒有記號查詢參數。 例如，GET /v1/projects/{project_id}/configs/?limit=5 OR GET /v1/projects/{project_id}/configs。
  • 當指定的頁面記號無效時，也會傳回第一頁。

list-環境

GET /v1/projects/{project_id}/environments

• 此作業現在已分頁。
• 如果未在 limit 查詢參數中指定頁面大小，則會傳回預設值 10 筆記錄。
  • 頁面大小上限為 100 筆記錄。
• 傳回的第一頁在要求 URL 中沒有 token 查詢參數。 例如，GET /v1/projects/{project_id}/environments/?limit=5 OR GET /v1/projects/{project_id}/environments。
  • 當指定的頁面記號無效時，也會傳回第一頁。

支援堆疊可部署架構的方法

實驗

已新增實驗性方法來支援 堆疊可部署架構。

專案和配置變更

create-project: POST /v1/projects

• 現在，resource_group 和 location 將內嵌在 request 有效負載中。 不再支援它們作為查詢參數。

delete-config: PATCH /v1/projects/{project_id}/configs/{id}

• draft_only 查詢參數已淘汰。
• API 現在支援刪除指定專案 ID 及 version 的 configuration。 請參閱 專案#delete-config-version。

重新命名的配置端點

下列配置端點已重新命名，如下所示:

• POST /v1/projects/{project_id}/configs/{id}/check 變更為 POST /v1/projects/{project_id}/configs/{id}/validate。
• POST /v1/projects/{project_id}/configs/{id}/install 變更為 POST /v1/projects/{project_id}/configs/{id}/deploy。
• POST /v1/projects/{project_id}/configs/{id}/uninstall 變更為 POST /v1/projects/{project_id}/configs/{id}/undeploy。

已取代配置端點

drafts 方法已由 versions 作業取代，如下所示:

• GET /v1/projects/{project_id}/configs/{config_id}/drafts 變更為 GET /v1/projects/{project_id}/configs/{id}/versions。
• GET /v1/projects/{project_id}/configs/{config_id}/drafts/{version} 變更為 GET /v1/projects/{project_id}/configs/{id}/versions/{version}

配置狀態

configurations 的狀態模型已壓縮。 pipeline_state 不再可用，現在已擴增一個 state 內容，以擷取 configuration 的所有可能狀態。

以下是新的 state 值:

• approved
• deleted
• deleting
• deleting_failed
• discarded
• deployed
• deploying_failed
• deploying
• superceded
• undeploying
• undeploying_failed
• validated
• validating
• validating_failed

所有 configuration 端點都在 response 模型中包括此 state 內容。 如需範例，請參閱 projects#get-config-version-response。

配置新的 meta 資料

configurations 作業的 response 模型現在會在根目錄中定義新的 meta 資料。 如果在 configuration 上執行 approve 工作，則會在 response 有效負載中包括 approved_version 內容。 同樣地，如果在 configuration 上執行 deploy 工作，則 response 內文中提供 deployed_version 及 last_deployed meta 資料。 執行 validation 工作會產生 meta 資料 last_validated，而執行 undeploy 工作會產生 response 中的 meta 資料 last_undeployed。

專案

create-project: POST /v1/projects

• For both the request & response, the name, description, and destroy_on_delete are now wrapped inside a definition object.
• 現在預期此端點的呼叫者會在此封套內提供定義內容，例如:
  • definition: {“name”: “test”, “description”: “This is a test project”, “destroy_on_delete”: false}.
    • 如果未提供 destroy_on_delete，則會在專案建立作業上指派預設值 true。
  • 請參閱 專案#create-project-request。
• 同樣地，在 response 主體中，現在可以在 definition 區塊中使用先前提及的內容。
  • 請參閱 專案#create-project-response。

update-project: PATCH /v1/projects/{id}

• For both the request & response, the name, description, and destroy_on_delete are now wrapped inside a definition object.
• 現在預期此端點的呼叫者會在此封套內提供定義內容，例如:
  • definition: {“name”: “test_update”, “description”: “This is an updated test project“}.
  • 請參閱 專案#update-project-request。
• 同樣地，在 response 主體中，現在可以在 definition 區塊中使用先前提及的內容。
  • 請參閱 專案#update-project-response。

get-projects: GET /v1/projects/{id}

• 在此作業的 response 中，name、description 及 destroy_on_delete 現在包裝在 definition 區塊內。
  • 請參閱 專案#get-project-response。

list-project: GET /v1/projects

• response 陣列中傳回的每一個專案都會將 name、description 及 destroy_on_delete 內容包裝在 definition 區塊中。
  • 請參閱 專案#list-projects-response。

配置

create-config: POST /v1/projects/{project_id}/configs

• For both request & response, the locator_id, name, labels, authorizations, compliance_profile, input, setting, description are now wrapped inside a definition object.
• 現在預期此端點的呼叫者會在此封套內提供定義內容，例如:
  • definition: {“name”: “test”, “description”: “This is a test config”, “locator_id”: “1082e7d2-5e2f-0a11-a3bc-f88a8e1931fc.cd596f95-95a2-4f21-9b84-477f21fd1e95-global”}.
  • 請參閱 專案#create-config-request。
• 同樣地，在 response 主體中，現在可以在 definition 區塊中使用先前提及的內容。
  • setting 內容也包含在 definition 區塊中。
  • 請參閱 專案#create-config-response。

update-config: PATCH /v1/projects/{project_id}/configs/{id}

• For both request & response, the locator_id, name, labels, authorizations, compliance_profile, input, setting, description are now wrapped inside a definition object.
• 現在預期此端點的呼叫者會在此封套內提供定義內容，例如:
  • definition: {“name”: “test”, “description”: “This is a test config”, “locator_id”: “1082e7d2-5e2f-0a11-a3bc-f88a8e1931fc.cd596f95-95a2-4f21-9b84-477f21fd1e95-global”}.
  • 請參閱 專案#update-config-request。
• 同樣地，在 response 主體中，先前提及的內容會移至 definition 區塊中。
  • 請參閱 專案#update-config-response。

get-config: GET /v1/projects/{id}

• 在這項作業的 response 中，locator_id、name、labels、authorizations、compliance_profile、input、setting、description 和 setting 現在包裝在 definition 物件內。
  • 請參閱 專案#get-config-response。

list-configs: GET /v1/projects/{project_id}/configs

• 在這項作業的 response 中，name 和 description 現在包裝在 definition 物件內。
  • 請參閱 專案#list-configs-response。