Git & Jenkins: obtenez le dernier engagement vert sur la branche

Nous commençons tout juste à faire pression pour le CI-CD et en tant que petit pas, nous allons essayer de mettre à jour une pile avec le dernier développement vert une fois toutes les deux heures. Je suis assez nouveau sur Git / Bitbucket, et je n'arrive pas à comprendre comment garantir que le paiement effectué par Jenkins obtient le dernier commit marqué en vert par Jenkins, plutôt que simplement "le dernier commit" en tant qu'instruction générale.

Le plug-in Bitbucket Build Status Notifier est installé, donc Bitbucket suit les validations vertes après l'exécution de nos tests unitaires. Existe-t-il un moyen de tirer parti de ces informations pour vous assurer que le bon commit est sélectionné?

Vous ne faites aucune mention du langage de script que vous souhaitez utiliser, je vais donc parler spécifiquement des requêtes HTTP à l'API BitBucket:

Hypothèses

Si vous avez un référentiel BitBucket contenant trois validations, le premier et le dernier échouent à la génération, le milieu passe:

• 4768815 ❌
• 49d7110 ✅
• 42d357f ❌

Obtenez la liste des commits

Vous pouvez obtenir la liste des validations en appelant la méthode API suivante:

https://api.bitbucket.org/2.0/repositories/{{owner}}/{{repo_slug}}/commits

• owner: RichardSlater
• repo_slug: greencommitproofofconcept

La réponse ressemble à ceci:

{
  "pagelen": 30,
  "values": [
    {
      "hash": "4768815fdc27abf4be17096e7c460f7f68f5d39b",
      "repository": { ... },
      "links": {
        ...
        "statuses": {
          "href": "https://api.bitbucket.org/2.0/repositories/RichardSlater/greencommitproofofconcept/commit/4768815fdc27abf4be17096e7c460f7f68f5d39b/statuses"
        }
      },
      "author": { ... },
      "parents": [ ... ],
      "date": "2017-04-10T11:38:18+00:00",
      "message": "README.md edited online with Bitbucket",
      "type": "commit"
    },
    {
      "hash": "49d7110b98616358d16055960a4abdf2926b890d",
      ...
    },
    {
      "hash": "42d357f1df7a7d7bcf1f10a9f3a5a40d85d5b11c",
      ...
    }
  ]
}

Si vous analysez le JSON et parcourez les réponses, vous pouvez extraire les statuts de:

values[n].links.statuses.href

Où nest l'indice, c'est-à-dire 0, 1ou 2dans l'exemple ci-dessus. Si vous deviez le construire à partir de zéro, ce serait dans le format suivant.

Obtenez la liste des statuts de la validation

https://api.bitbucket.org/2.0/repositories/{{owner}}/{{repo_slug}}/commit/{{sha}}/statuses"

• owner: RichardSlater
• repo_slug: greencommitproofofconcept
• sha: 4768815fdc27abf4be17096e7c460f7f68f5d39b

Remarque: il s'agit d'une API Hypermedia qui signifie que les URL peuvent changer, donc je recommanderais d'utiliser les liens de la réponse précédente plutôt que d'essayer de les générer à partir de zéro.

La réponse de la demande HTTP ci-dessus sera quelque chose comme:

{
  "pagelen": 10,
  "values": [
    {
      "key": "POC-01",
      "name": "Build #1",
      "repository": { ... },
      "url": "http://devops.stackexchange.com/q/809/397",
      "links": { ... },
      "refname": null,
      "state": "FAILED",
      "created_on": "2017-04-10T13:04:28.261734+00:00",
      "updated_on": "2017-04-10T13:04:28.261759+00:00",
      "type": "build",
      "description": "Changes by Richard Slater"
    }
  ],
  "page": 1,
  "size": 1
}

De cette réponse, vous pouvez extraire l' stateutilisation de:

values[n].state

Encore une fois, où nest le status- il pourrait y en avoir beaucoup si un commit aboutissait à plusieurs builds.

Si l'état de la construction qui vous intéresse est SUCCESSFULalors vous avez votre réponse et vous pouvez immédiatement retourner le shapour le commit.

Parcourez toutes les validations de la première phase, si vous manquez de validations, suivez la nextpage linkincluse dans l'appel à /commits.

Diagramme de flux complet

À un niveau élevé, le flux ressemblera à ceci:

N'oubliez pas qu'il s'agit d'une API Hypermedia . Dans la mesure du possible, demandez à votre code de suivre les liens dans l'API plutôt que d'essayer de les "deviner".

Dans un pipeline de livraison / déploiement continu typique, les événements suivants se produisent:

1. Le développeur envoie une ou plusieurs validations, ou une demande d'extraction est fusionnée.
2. Jenkins construit et exécute automatiquement des tests.
3. En cas de succès, Jenkins publie un package de déploiement dans un référentiel d'artefacts; si l'échec ne publie rien et informe les développeurs.
4. L'automatisation du déploiement utilise des packages du référentiel Artefact et les déploie.

Le but est d'éviter de construire la solution à partir de la source deux fois, de la construire une fois et de la déployer plusieurs fois. Vous pouvez implémenter les approbations dans Sonartype Nexus pour définir le processus d'approbation de l'environnement, à savoir Dev → Test → UAT → Stage → Production.

Cela dit ... si vous avez lu tout ce qui précède et que vous souhaitez toujours obtenir la dernière version verte du contrôle de source, vous pouvez utiliser l'une des deux techniques suivantes:

1. Demandez à Jenkins d'étiqueter la branche avec une étiquette nommée de manière appropriée, c'est-à-dire master-greenensuite utilisez-la plutôt que masterlorsque vous voulez la dernière version verte.
2. Les bitbucket commits pour obtenir une liste de livraisons et COMMIT / {sha} / statuts sur chacun de trouver la commettras avec un statut vert. J'ai développé cette solution dans une autre réponse .

N'hésitez pas à poster une question de suivi si vous souhaitez des détails spécifiques sur la façon d'utiliser les approches ci-dessus.