Comments 14
Согласен, про REST API невнятно вышло. Зачем вообще он упомянут? Вот есть такой тикет https://gitlab.com/gitlab-org/gitlab-ce/issues/21911 — он про права пользователей на запуск задач, на запуск задач в определённых environment, на доступ к секретным переменным, на доступ к раннерам. Когда это будет в gitlab, то права пользователям будем выдавать в интерфейса gitlab-а и не надо будет никаких "самописных с боку систем с REST API".
Переменная GITLAB_USER_EMAIL это email того, кто запускает задачу в пайплайне, а не email последнего коммитера. Ваш вариант пригодился бы, как решение проблемы с правкой .gitlab-ci.yml, однако email последнего коммитера в общем случае не обязан совпадать с email того, кто пушит.
Есть ли билды в контейнерах, используете чистый докер имидж или свои?
При монтировании .gradle папки как volume билд валится с ошибкой
Failed to load native library 'libnative-platform.so' for Linux amd64
что то похожее высказывалось здесь, но в последней версии gradle все так же(используется docker in docker и официальный gradle image https://hub.docker.com/_/gradle/)
Можете что-нибудь посоветовать?
По вашей ссылке сказано, что проблема из-за версий glibc и скорее всего в официальном gradle image старая версия glibc, либо проблема из-за использования alpine с его musl-libc — мы тоже на эти грабли наступили, правда в другом случае https://github.com/flant/dapp/issues/164.
Я так понял, вам было бы интересно узнать, как не перекачивать лишний раз java-артефакты или вообще чтобы скачивать только те, у которых версия изменилась? Немножко за рамками темы статьи на самом деле, но попробую ответить.
Мы в основном не используем возможности gitlab-а по сборке через docker, а используем свою утилиту dapp. В ней реализована поддержка сборки отдельных образов и копирование файлов из этих образов в финальный. На поверхности это похоже на multi stages в последних версиях docker, но есть и существенные отличия, как минимум dapp знает про git и dapp собирает образы по стадиям, что даёт возможность пересобирать только те стадии, для которых изменились указанные файлы.
Для примера в вашем случае в Dappfile будет описан отдельный образ в котором живёт gradle (можно указать, что он на основе официального gradle), куда при сборке подключится .gradle и где выполнится gradle build по исходникам.
После из этого образа скопируются указанные war, jar, ear или вся папка target в указанное место в финальном образе.
Т.к. dapp знает про git, то можно на одной стадии попросить gradle скачать свежие версии зависимостей, если изменился build.gradle (времязатратная стадия, но изменения редки, поэтому будет пересобираться не часто), а на следующей стадии gradle будет собирать проект, если изменились исходники в src.
Есть несколько веток, который нудно сливать в мастер автоматически после коммита.
Но как студент, нутром чувствую, что просто, а понять пока не могу.
подскажите?
Если сливать именно после коммита (git commit), то достаточно git хуков в локальном репозитории. Если же после push или после принятия MR, то хуки в gitlab. Ещё есть кнопка merge when build succeeds — но это наверно другая история.
deploy to dev-1:
<<: *staging-deploy-common
что значит эта деректива, что она делает?
Во-первых, откуда вы её взяли? В статье поиском не нашёл.
Во-вторых, если всё же открыть документацию, то там очень понятно с примерами написано, что это ссылка на якорь. Это значит, что в это место подставится содержимое staging-deploy-common
(если прям по простому объяснить).
Ну и вопросы лучше задавать на Тостер'е.
Это простой шаблонизатор yaml, встроенный в gitlab.
.job_template: &job_definition # Hidden key that defines an anchor named 'job_definition'
image: ruby:2.1
services:
- postgres
- redis
test1:
<<: *job_definition # Merge the contents of the 'job_definition' alias
script:
- test1 project
test2:
<<: *job_definition # Merge the contents of the 'job_definition' alias
script:
- test2 project
GitLab CI для непрерывной интеграции и доставки в production. Часть 2: преодолевая трудности