bump deploy --mcp-server

[Polo2]

Currently, send request to the Bump API,
to endpoint
POST /api/v1/workflow/version

API design in discussion, cf https://github.com/bump-sh/bump/pull/8134

TODO:

• adapt with API endpoint changes (cf https://github.com/bump-sh/bump/pull/8134)
• add tests for this new command bump deploy --mcp-server
• fix the existing failing tests (last commit but not sure, can we discuss?)
• favor authenticate via Token, not Basic (dedicated PR -> api: use token based authorization method #786 )
• refacto: remove methods about workflow from core/deploy.ts,
  favor a dedicated file ?
• refacto: rename Api to Definition (dedicated PR)

[Polo2]

The test expect((api.overlayedDefinition as APIDefinition).info.description).to.match(/Protect Earth's Tree Tracker API/)
is failing, because APIDefinition may be a Flower, where info is missing.

Naïve solution would be to force object info in Flower specification, or we need to clean a bit more how ApiDefinition type is used, exported, imported.

[Polo2]

cc @paulRbr , les points en discussion sont dans les 3 derniers commits dédiés:

• est-ce pertinent de scinder un CoreDeploy et un WorkflowCoreDeploy? Je ne vois finalement quasiment aucun code partagé entre ces deux fichiers (à part la fonction d, réponse D?)
• est-ce pertinent de traiter en fonction du status de la réponse (201 ou 204) plutôt que sur la présence d'une réponse (guesswork) dans deploySingleWorkflowFile ?

[paulRbr]

• est-ce pertinent de scinder un CoreDeploy et un WorkflowCoreDeploy?

Je crois que c'est plus simple de garder une seul lib CoreDeploy (c'est celle là qu'on réutilise dans la GH action pour info), c'est elle qui tient le client d'API, et la responsabilité de « run » le deploy en fonction de la definition d'API. Mais je comprends que tous les paramètrs de la méthode run actuelle soit un peu déroutant. J'aime bien la version avec runWorkflow dans CoreDeploy je crois.

Mais en réalité j'ai pas d'avis fort. Comme tu veux! (Il faudra juste bien penser à exporter la nouvelle lib WorkflowCoreDeploy si tu vas dans cette direction pour que la github action puisse l'utiliser.

• est-ce pertinent de traiter en fonction du status de la réponse (201 ou 204) plutôt que sur la présence d'une réponse (guesswork) dans deploySingleWorkflowFile ?

Je trouve ça contre-intuitif de passer le code de status HTTP dans l'objet WorkflowVersionResponse. Pour moi il faut traiter le code HTTP (201 ou 204) juste après l'appel d'API, puis si on a besoin de faire quelque chose plus tard en fonction du résultat, il faut l'encoder dans l'objet de réponse que l'on a construit à partir du response body de l'API. Je suis pas sûr de comprendre ce que cela apporte d'avoir le status de la requête HTTP dans l'objet que l'on traite après?

[Polo2]

Je trouve ça contre-intuitif de passer le code de status HTTP dans l'objet WorkflowVersionResponse. Pour moi il faut traiter le code HTTP (201 ou 204) juste après l'appel d'API, puis si on a besoin de faire quelque chose plus tard en fonction du résultat, il faut l'encoder dans l'objet de réponse que l'on a construit à partir du response body de l'API. Je suis pas sûr de comprendre ce que cela apporte d'avoir le status de la requête HTTP dans l'objet que l'on traite après?

On reprendra la discussion lundi du coup, mais je voulais éviter la logique où l'on devine qu'il s'agit d'une 201 (et que aucune version n'est créé car la document fourni est similaire à la précédente version), comme actuellement implémenté côté api version:

https://github.com/bump-sh/cli/blob/v2.9.11/src/commands/deploy.ts#L172-L180

Mais en réalité j'ai pas d'avis fort. Comme tu veux! (Il faudra juste bien penser à exporter la nouvelle lib WorkflowCoreDeploy si tu vas dans cette direction pour que la github action puisse l'utiliser.

Merci pour le retour, je prévoyais de regarder aujourd'hui la partie GitHub action, je pourrais donc faire le meilleur choix possible ©️ en connaissance de cause. dans tous les cas il s'agit d'un seul commit, facile à revert ou cherry-pick si besoin