Git & Jenkins: ottieni l'ultimo commit verde sulla filiale

Stiamo appena iniziando a spingere per CI-CD e come un piccolo passo proveremo ad aggiornare uno stack con l'ultimo sviluppo verde una volta ogni due ore. Sono abbastanza nuovo su Git / Bitbucket e non riesco a capire come garantire che il checkout che Jenkins esegua ottenga che l'ultimo commit sia stato contrassegnato in verde da Jenkins, piuttosto che solo "l'ultimo commit" come una dichiarazione generale.

Abbiamo installato il plug-in Bitbucket Build Status Notifier , quindi Bitbucket tiene traccia dei commit che sono verdi dopo l'esecuzione dei test delle unità. C'è un modo per sfruttare queste informazioni per assicurarsi che venga scelto il giusto commit?

Non fai alcuna menzione del linguaggio di script che desideri utilizzare, quindi parlerò in modo specifico delle richieste HTTP all'API BitBucket:

ipotesi

Se hai un repository BitBucket con tre commit al suo interno, il primo e l'ultimo non riescono a compilare , il centro sta passando:

• 4768815 ❌
• 49d7110 ✅
• 42d357f ❌

Ottieni l'elenco dei commit

Puoi ottenere l'elenco dei commit chiamando il seguente metodo API:

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

• owner: RichardSlater
• repo_slug: greencommitproofofconcept

La risposta è simile alla seguente:

{
  "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",
      ...
    }
  ]
}

Se analizzi JSON e esegui il ciclo delle risposte, puoi estrarre gli stati da:

values[n].links.statuses.href

Dov'è nl'indice, ovvero 0, 1o 2nell'esempio sopra. Se dovessi costruirlo da zero sarebbe nel seguente formato.

Ottieni l'elenco degli stati dal commit

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

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

Nota: questa è un'API Hypermedia che significa che gli URL potrebbero cambiare, quindi consiglierei di usare i collegamenti della risposta precedente piuttosto che provare a generarli da zero.

La risposta dalla richiesta HTTP sopra sarà simile a:

{
  "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
}

Da questa risposta è possibile estrarre l' stateutilizzo di:

values[n].state

Di nuovo dov'è nil status- potrebbero essercene molti se un commit ha portato a molte build.

Se lo stato per il build che ti interessa è SUCCESSFULallora hai la tua risposta e puoi immediatamente restituire il shaper il commit.

Passa in rassegna tutti i commit dalla prima fase, se finisci i commit segui la nextpagina linkinclusa nella chiamata a /commits.

Diagramma di flusso completo

Ad un livello elevato il flusso sarà simile al seguente:

Non dimenticare che si tratta di un'API Hypermedia, quindi, ove possibile, fai in modo che il tuo codice segua i collegamenti nell'API anziché cercare di "indovinarli".

In una tipica pipeline di distribuzione / distribuzione continua si verifica quanto segue:

1. Lo sviluppatore invia uno o più commit oppure una richiesta pull viene unita.
2. Jenkins costruisce ed esegue automaticamente i test.
3. In caso di successo, Jenkins pubblica un pacchetto di distribuzione in un repository Artefact; se il fallimento non pubblica nulla e avvisa gli sviluppatori.
4. L'automazione della distribuzione utilizza i pacchetti dal repository Artefact e li distribuisce.

L'obiettivo è evitare di creare due volte la soluzione dalla fonte, la costruisci una volta e la distribuisci molte volte. È possibile implementare le approvazioni in Sonartype Nexus per definire il processo di approvazione dell'ambiente, ovvero Dev → Test → UAT → Stage → Produzione.

Detto questo ... se hai letto tutto il precedente e vuoi ancora ottenere l'ultima build verde dal controllo del codice sorgente, puoi usare una delle due tecniche:

1. Chiedi a Jenkins di taggare il ramo con un tag con un nome appropriato, master-greenquindi usalo al posto di masterquando vuoi l'ultima build verde.
2. Utilizzare i commit di BitBucket per ottenere un elenco di commit e gli stati / {sha} / stati su ciascuno per trovare il commit con uno stato verde. Ho ampliato questa soluzione in un'altra risposta .

Sentiti libero di pubblicare una domanda di follow-up se desideri i dettagli specifici su come utilizzare gli approcci sopra.