list-项目

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 字段不再受支持，也不再包含在响应有效内容中。

列表配置

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 现在支持删除指定项目标识和 version 的 configuration。 请参阅 projects#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。

配置新元数据

configurations 操作的 response 模型现在在根中定义新的元数据。 如果在 configuration 上运行了 approve 作业，那么 approved_version 属性将包含在 response 有效内容中。 同样，如果 deploy 作业在 configuration 上运行，那么 deployed_version 和 last_deployed 元数据在 response 主体中可用。 运行 validation 作业将生成元数据 last_validated，而运行 undeploy 作业将生成 response 中的元数据 last_undeployed。

项目

create-project: POST /v1/projects

• 对于 request 和 response，name，description 和 destroy_on_delete 现在都打包在 definition 对象中。
• 现在期望此端点的调用者在此包装器中提供定义属性，例如:
  • definition: {“name”: “test”, “description”: “This is a test project”, “destroy_on_delete”: false}.
    • 如果未提供 destroy_on_delete，那么将在项目创建操作上指定缺省值 true。
  • 请参阅 projects#create-project-request。
• 同样，在 response 主体中，先前提到的属性现在在 definition 块中可用。
  • 请参阅 项目#create-project-response。

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

• 对于 request 和 response，name，description 和 destroy_on_delete 现在都打包在 definition 对象中。
• 现在期望此端点的调用者在此包装器中提供定义属性，例如:
  • definition: {“name”: “test_update”, “description”: “This is an updated test project“}.
  • 请参阅 projects#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 块中。
  • 请参阅 projects#list-projects-response。

配置

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

• 对于 request 和 response，现在将 locator_id，name，labels，authorizations，compliance_profile，input，setting 和 description 包装在 definition 对象中。
• 现在期望此端点的调用者在此包装器中提供定义属性，例如:
  • definition: {“name”: “test”, “description”: “This is a test config”, “locator_id”: “1082e7d2-5e2f-0a11-a3bc-f88a8e1931fc.cd596f95-95a2-4f21-9b84-477f21fd1e95-global”}.
  • 请参阅 projects#create-config-request。
• 同样，在 response 主体中，先前提到的属性现在在 definition 块中可用。
  • setting 属性也包含在 definition 块中。
  • 请参阅 项目#create-config-response。

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

• 对于 request 和 response，现在将 locator_id，name，labels，authorizations，compliance_profile，input，setting 和 description 包装在 definition 对象中。
• 现在期望此端点的调用者在此包装器中提供定义属性，例如:
  • definition: {“name”: “test”, “description”: “This is a test config”, “locator_id”: “1082e7d2-5e2f-0a11-a3bc-f88a8e1931fc.cd596f95-95a2-4f21-9b84-477f21fd1e95-global”}.
  • 请参阅 projects#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。