Pull to refresh

Comments 14

А для чего REST-API? Можно же получить имя и email того кто сделал коммит прямо в .gitlab-ci.yml:
USER_NAME=$(git log -1 —pretty=%an)
USER_EMAIL=$(git log -1 —pretty=%ae)
COMMIT_MESSAGE=$(git log -1 —pretty=%B)

Форматы для pretty тут

Согласен, про 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 того, кто пушит.

С трудом представляю. Гита нет в Гитлабе?

Если используется директива image: то команды будут запускаться через указанный там образ. И вот в этом образе может не быть команды git.

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

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

При монтировании .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.

совсем недавно пришлось работать с Gitlab и возник, казалось бы, простой вопрос.
Есть несколько веток, который нудно сливать в мастер автоматически после коммита.
Но как студент, нутром чувствую, что просто, а понять пока не могу.
подскажите?
Вам ответили ниже, но коллега промахнулся веткой, так что вы могли не заметить :-)

Если сливать именно после коммита (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

https://docs.gitlab.com/ee/ci/yaml/#anchors

Sign up to leave a comment.