Использование gitlab continuous integration для деплоя

[arren]

Вкусно, но рецепт можно сделать так, чтобы деплой делался только при пуше (или аппруве мерж реквеста) в отдельную ветку, типа deploy или release, или еще как-то обозначающую, что это именно в релиз, а все остальные ветки, и даже теги, тестировать на других раннерах. Мастер, к примеру, можно выкатывать на тестовую среду, если таковая имеется.

[abcdmitry]

Это настраивается на уровне .gitlab-ci.yml — директивы only и except в описании задачи doc.gitlab.com/ci/yaml/README.html

[arren]

Спасибо, но это был не вопрос. По предложенной схеме мы работаем.

[mickvav]

а если мы сам yuml-файлик пушим, оно как его тестит?

[grigoryvp]

Не понял вопроса. «Оно» и «Его» — это кто такие? О_О

[nmike]

Тестит сам файлик? Вот тут в самом низу есть

Validate the .gitlab-ci.yml

Each instance of GitLab CI has an embedded debug tool called Lint. You can find the link to the Lint in the project's settings page or use short url /lint.

[grigoryvp]

Нужно добавить в .yaml файл вызов /lint с указанием этого файла.

[nmike]

— curl -X POST «api.voximplant.com/platform_api/SetScenarioInfo/?account_id=1&api_key=2&required_scenario_name=foo» --data-urlencode [e-mail]

вот тут вы предлагаете приватные данные прям в репозиторий пушить? так нельзя делать.
Для этого есть Variables

Storing API keys

In GitLab CI 7.12 a new feature was introduced: Secure Variables. Secure Variables can added by going to Project > Variables > Add Variable. This feature requires gitlab-runner with version equal or greater than 0.4.0. The variables that are defined in the project settings are send along with the build script to the runner. The secure variables are stored out of the repository. Never store secrets in your projects' .gitlab-ci.yml. It is also important that secret's value is hidden in the build log.

[grigoryvp]

Согласен. Увы, если в статье писать вообще все что в настоящем ci делается — это будет wall of text, который никто никогда не будет читать :)

[Monnoroch]

Я столкнулся с проблемой, что когда я делаю пуллреквест, тесты запускаются только на последнем коммите пуллреквеста, что провоцирует методологию разработки «сделай как-нибудь, а потом допили до зеленой кнопочки».
Может, кто-то смог это решить?

[grigoryvp]

Ммм… Ну вообще DVCS именно так работает — мы коммитим-коммитим-коммимтим локально, а когда оно все готово и собирается — пушим и оно делает тест по последнему коммиту. Промежуточные как бы показывают процесс работы, оно и не должно собираться/тестироваться. Если я правильно понял вопрос, конечно :)

[Monnoroch]

С моей точки зрения, каждый коммит должен быть (to the best of developers knowledge) рабочим чекпоинтом в жизни приложения. Все промежуточные нерабочие коммиты сквошатся в кошерные рабочие во время создания пуллреквеста.
Собственно, это следствие названия continious deployment. Если бы только некоторые коммиты представляли собой рабочие версии, deployment был бы не continious а какой-то discrete что-ли.

[grigoryvp]

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

[Monnoroch]

Гранулярность коммитов — это ортогональный вопрос, я не предлагаю же все в один запихать. Чем больше, тем лучше, но работать должен каждый, чтобы сделать deployment continious.
Собственно, это все, наверное, философия, но факт в том, что я долго ковырялся в интернетах и так и не нашел, как запускать тесты на всех коммитах пуллреквеста. Вопрос-то про это был.

[grigoryvp]

Видимо это от того, что большинство разработчиков придерживается того же подхода что и я: коммиты — штука промежуточная, результат работы — это пуш. Проверять надо только результат работы.

Чем помочь вам не знаю :(. На вскидку — форкнуть gitlab и сделать нужное поведение в коде. Но это вызывает множество вопросов с отображением, останавливаться ли если очередной коммит не прошел тесты, делать ли деплой на последнем или на всех… Вообщем странная и сложная штука. Если так нужно — дерзайте!

[Monnoroch]

Я тоже пока вынужденно вашего метода придерживаюсь, но это только от безысходности :(

[nmike]

ну так настройте пушь после каждого коммита — будет вам счастье.

[Monnoroch]

Что это значит? Я же не в мастер коммичу, я делаю бранч, в нем работаю, а потом делаю пуллреквест. И хочется запрещать мерж пуллреквеста, если в нем есть плохой коммит.

[nmike]

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

методологию разработки «сделай как-нибудь, а потом допили до зеленой кнопочки».

Вообще, вам не это вероятно надо, а настроить хуки на прогон тестов на локальной машине на каждый коммит и реджектить его, пока не станет «зеленым».

Просто не понятно, вот вы сделали 10 комитов в ветку и пушите. И на сервере есть проверка каждого коммита. И вот у вас 7 завалилось — чем это лучше? и что вы будут делать на сервере с уже запушинными «красными» комитами?

[asm0dey]

Зависит от того, придерживаетесь ли вы идеи с фичебранчами. Мне они нравятся как раз тем, что там можно творить любой ад и это не портит главную ветку репозитория. Бывают гигантские задачи с огромными по объёму рефакторингами. Закоммитить их в рабочем состоянии посередине может быть нереально.

[Monnoroch]

При чем тут фичебранчи? Какой бы ветка ни была, при мерже её в мастер либо сквошить и терять историю, либо не сквошить и портить мастер плохими коммитами, либо пускать тесты как-то не через систему.

[asm0dey]

Я не совсем понимаю почему мастер будет испорчен плохими коммитами. Мы ж не ребэйзим, мы мёрджим, так? В мастере будет один коммит про то, что смёрджен бранч такой-то, какие бы коммиты в этом бранче не были.

[mird]

А так откатили коммит и получили не рабочую версию. Непорядок.