liste-projets

GET /v1/projects

• Le paramètre de requête de jeton de page start a été renommé en token.
  • Par exemple, l'appel de l'opération list-projects est passé de GET /v1/projects?limit=5&start={page_token} à GET /v1/projects?limit=5&token={page_token}.
• La première page est renvoyée sans le paramètre de requête de jeton dans l'URL de la demande. Par exemple, GET /v1/projects?limit=5 ou GET /v1/projects.
  • La première page est également renvoyée lorsque le jeton de page spécifié n'est pas valide.
• Les zones last et previous ne sont plus prises en charge et ne sont plus incluses dans le contenu de la réponse.

configs-liste

GET /v1/projects/{project_id}/configs

• Cette opération est maintenant mise en page.
• Une valeur par défaut de 10 enregistrements est renvoyée si la taille de page n'est pas spécifiée dans le paramètre de requête limit.
  • La taille de page maximale est de 100 enregistrements.
• La première page est renvoyée sans le paramètre de requête de jeton dans l'URL de la demande. Par exemple, GET /v1/projects/{project_id}/configs/?limit=5 ou GET /v1/projects/{project_id}/configs.
  • La première page est également renvoyée lorsque le jeton de page spécifié n'est pas valide.

environnements de liste

GET /v1/projects/{project_id}/environments

• Cette opération est maintenant mise en page.
• Une valeur par défaut de 10 enregistrements est renvoyée si la taille de page n'est pas spécifiée dans le paramètre de requête limit.
  • La taille de page maximale est de 100 enregistrements.
• La première page est renvoyée sans le paramètre de requête token dans l'URL de la demande. Par exemple, GET /v1/projects/{project_id}/environments/?limit=5 ou GET /v1/projects/{project_id}/environments.
  • La première page est également renvoyée lorsque le jeton de page spécifié n'est pas valide.

Méthodes de prise en charge de l'empilement des architectures déployables

Version expérimentale

Ajout de méthodes expérimentales pour la prise en charge de l'empilement des architectures déployables.

Modifications apportées aux projets et aux configurations

create-project: POST /v1/projects

• Les resource_group et location doivent maintenant être imbriqués dans le contenu request. Ils ne sont plus pris en charge en tant que paramètres de requête.

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

• Le paramètre de requête draft_only est obsolète.
• L'API prend désormais en charge la suppression de configuration d'un ID de projet spécifié et de version. Voir projets#delete-config-version.

Noeuds finaux de configuration renommés

Les noeuds finaux de configuration suivants sont renommés comme suit:

• POST /v1/projects/{project_id}/configs/{id}/check est remplacé par POST /v1/projects/{project_id}/configs/{id}/validate.
• POST /v1/projects/{project_id}/configs/{id}/install est remplacé par POST /v1/projects/{project_id}/configs/{id}/deploy.
• POST /v1/projects/{project_id}/configs/{id}/uninstall est remplacé par POST /v1/projects/{project_id}/configs/{id}/undeploy.

Noeuds finaux de configuration remplacés

Les méthodes drafts ont été remplacées par les opérations versions comme suit:

• GET /v1/projects/{project_id}/configs/{config_id}/drafts est remplacé par GET /v1/projects/{project_id}/configs/{id}/versions.
• GET /v1/projects/{project_id}/configs/{config_id}/drafts/{version} est remplacé par GET /v1/projects/{project_id}/configs/{id}/versions/{version}

Etats de configuration

Le modèle d'état de configurations est mis à plat. Le pipeline_state n'est plus disponible et la propriété state est désormais étendue pour capturer tous les statuts possibles d'un configuration.

Les nouvelles valeurs state sont les suivantes:

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

Tous les noeuds finaux configuration incluent cette propriété state dans le modèle response. Pour un exemple, voir projects#get-config-version-response.

Nouvelles métadonnées de configuration

Le modèle response des opérations configurations définit désormais de nouvelles métadonnées dans la racine. Si un travail approve a été exécuté sur un configuration, une propriété approved_version est incluse dans le contenu response. De même, si un travail deploy a été exécuté sur un configuration, les métadonnées deployed_version et last_deployed sont disponibles dans le corps response. L'exécution d'un travail validation génère les métadonnées last_validated, tandis que l'exécution d'un travail undeploy génère les métadonnées last_undeployed dans response.

Projets

create-project: POST /v1/projects

• Pour request & response, name, description et destroy_on_delete sont désormais encapsulés dans un objet definition.
• Les appelants de ce noeud final sont désormais censés fournir les propriétés de définition dans cet encapsuleur, par exemple:
  • definition: {“name”: “test”, “description”: “This is a test project”, “destroy_on_delete”: false}.
    • Si destroy_on_delete n'est pas fourni, la valeur par défaut true est affectée à une opération de création de projet.
  • Voir projects#create-project-request.
• De même, dans le corps response, les propriétés mentionnées précédemment sont désormais disponibles dans un bloc definition.
  • Voir projects#create-project-response.

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

• Pour request & response, name, description et destroy_on_delete sont désormais encapsulés dans un objet definition.
• Les appelants de ce noeud final sont désormais censés fournir les propriétés de définition dans cet encapsuleur, par exemple:
  • definition: {“name”: “test_update”, “description”: “This is an updated test project“}.
  • Voir projects#update-project-request.
• De même, dans le corps response, les propriétés mentionnées précédemment sont désormais disponibles dans un bloc definition.
  • Voir projects#update-project-response.

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

• Dans le response de cette opération, les name, description et destroy_on_delete sont désormais encapsulés dans un bloc definition.
  • Voir projects#get-project-response.

list-project: GET /v1/projects

• Chaque projet renvoyé dans le tableau response encapsule les propriétés name, description et destroy_on_delete dans un bloc definition.
  • Voir projects#list-projects-response.

Configurations

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

• Pour request & response, les éléments locator_id, name, labels, authorizations, compliance_profile, input, setting, description sont désormais encapsulés dans un objet definition.
• Les appelants de ce noeud final sont désormais censés fournir les propriétés de définition dans cet encapsuleur, par exemple:
  • definition: {“name”: “test”, “description”: “This is a test config”, “locator_id”: “1082e7d2-5e2f-0a11-a3bc-f88a8e1931fc.cd596f95-95a2-4f21-9b84-477f21fd1e95-global”}.
  • Voir projets#create-config-request.
• De même, dans le corps response, les propriétés mentionnées précédemment sont désormais disponibles dans un bloc definition.
  • Une propriété setting est également incluse dans le bloc definition.
  • Voir projects#create-config-response.

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

• Pour request & response, les éléments locator_id, name, labels, authorizations, compliance_profile, input, setting, description sont désormais encapsulés dans un objet definition.
• Les appelants de ce noeud final sont désormais censés fournir les propriétés de définition dans cet encapsuleur, par exemple:
  • definition: {“name”: “test”, “description”: “This is a test config”, “locator_id”: “1082e7d2-5e2f-0a11-a3bc-f88a8e1931fc.cd596f95-95a2-4f21-9b84-477f21fd1e95-global”}.
  • Voir projets#update-config-request.
• De même, dans le corps response, les propriétés mentionnées précédemment sont déplacées dans un bloc definition.
  • Voir projects#update-config-response.

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

• Dans le response de cette opération, les éléments locator_id, name, labels, authorizations, compliance_profile, input, setting, description et setting sont désormais encapsulés dans un objet definition.
  • Voir projects#get-config-response.

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

• Dans le response de cette opération, les éléments name et description sont désormais encapsulés dans un objet definition.
  • Voir projects#list-configs-response.