Git & Jenkins: получите последний зеленый коммит на ветке

Мы только начинаем настаивать на выпуске CI-CD, и в качестве детского шага мы попытаемся обновлять стек новейшими разработками раз в пару часов. Я довольно новичок в Git / Bitbucket и не могу понять, как обеспечить, чтобы проверка, которую делает Дженкинс, помечала Дженкинсом последний коммит, а не просто «последний коммит» как общий оператор.

У нас установлен плагин Bitbucket Build Status Notifier , поэтому Bitbucket отслеживает, какие коммиты имеют зеленый цвет после запуска наших модульных тестов. Есть ли способ использовать эту информацию, чтобы убедиться, что выбран правильный коммит?

Вы не упоминаете язык сценариев, который хотите использовать, поэтому я буду говорить конкретно о HTTP-запросах к API BitBucket:

Предположения

Если у вас есть репозиторий BitBucket, в котором есть три коммита, первый и последний потерпели неудачу при сборке, середина проходит:

• 4768815 ❌
• 49d7110 ✅
• 42d357f ❌

Получить список коммитов

Вы можете получить список коммитов, вызвав следующий метод API:

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

• owner: RichardSlater
• repo_slug: greencommitproofofconcept

Ответ выглядит так:

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

Если вы анализируете JSON и перебираете ответы, вы можете извлечь статусы из:

values[n].links.statuses.href

Где nэто индекс, то есть 0, 1или 2в приведенном выше примере. Если бы вы построили это с нуля, это было бы в следующем формате.

Получить список статусов от коммита

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

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

Примечание: это Hypermedia API, который означает, что URL-адреса могут измениться, поэтому я бы рекомендовал использовать ссылки из предыдущего ответа, а не пытаться сгенерировать их с нуля.

Ответ от вышеуказанного HTTP-запроса будет примерно таким:

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

Из этого ответа вы можете извлечь stateиспользуя:

values[n].state

Опять же, где nэто status- там может быть много , если один коммит привел многие сборки.

Если состояние для сборки, о которой вы заботитесь, SUCCESSFULзначит, у вас есть ответ, и вы можете немедленно вернуть shaкоммит.

Зацикливайтесь на всех коммитах с первой фазы, если у вас кончились коммиты, перейдите на nextстраницу, linkкоторая включена в вызов /commits.

Полная блок-схема

На высоком уровне поток будет выглядеть так:

Не забывайте, что это API-интерфейс Hypermedia, поэтому, по возможности, ваш код должен следовать ссылкам в API, а не пытаться их «угадать».

В типичном конвейере непрерывной доставки / развертывания происходит следующее:

1. Разработчик выдвигает одну или несколько фиксаций или объединяет запрос на извлечение.
2. Дженкинс автоматически создает и выполняет тесты.
3. В случае успеха Jenkins публикует пакет развертывания в хранилище артефактов; если провал ничего не публикует и уведомляет разработчиков.
4. Автоматизация развертывания использует пакеты из хранилища артефактов и развертывает их.

Цель состоит в том, чтобы избежать создания решения из исходного кода дважды, вы создаете его один раз и развертываете его много раз. Вы можете реализовать утверждения в Sonartype Nexus, чтобы определить процесс утверждения среды, т. Е. Dev → Test → UAT → Stage → Production.

Тем не менее ... если вы прочитали все предыдущие и все еще хотите получить последнюю зеленую сборку из системы контроля версий, тогда вы можете использовать один из двух методов:

1. Попросите Дженкинса пометить ветку соответствующим именем, т. Е. master-greenЗатем использовать его вместо того master, чтобы использовать последнюю зеленую сборку.
2. Используйте коммиты BitBucket, чтобы получить список коммитов и зафиксировать / {sha} / состояния по каждому из них, чтобы найти коммит со статусом Green. Я расширил это решение в другом ответе .

Не стесняйтесь задавать дополнительный вопрос, если вы хотите узнать подробности о том, как использовать вышеуказанные подходы.