Как вы выкачиваете последний git tag в Gitlab CI?

Question

[Антон Пацев]

Имеется 2 стадии Gitlab CI

release:
  stage: release
  image: "$build_img"
  script:
    - apt-get install -y openssh-client git
    - mkdir -p ~/.ssh
    - echo "$SSH" | tr -d '\r' > ~/.ssh/id_rsa
    - chmod 600 ~/.ssh/id_rsa
    - eval "$(ssh-agent -s)"
    - ssh-add ~/.ssh/id_rsa
    - ssh-keyscan gitlab >> ~/.ssh/known_hosts
    - echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config
    - git config user.name $PUSH_USER_NAME
    - git config user.email $PUSH_USER_EMAIL
    - git remote set-url origin $SSH_GIT_URL
    - git checkout master
    - git reset --hard origin/master
    - mvn $MAVEN_CLI_OPTS clean release:prepare -Dresume=false -DautoVersionSubmodules=true -DdryRun=false -Dmaven.test.skip=true -DskipITs -DscmCommentPrefix="Release pom [ci skip]"
  only:
    - master

build_docker_container:
  stage: dockerize
  script:
    - git status
    - git reset --hard $(git describe --abbrev=0 --tags)
    - git status
    - docker login -u "$CI_REGISTRY_USER" -p $CI_JOB_TOKEN $CI_REGISTRY
    - docker build --pull -t "$CI_REGISTRY_IMAGE/$CI_PROJECT_NAME-$CI_COMMIT_REF_SLUG:$(git describe --abbrev=0 --tags)" .
    - docker push "$CI_REGISTRY_IMAGE/$CI_PROJECT_NAME-$CI_COMMIT_REF_SLUG:$(git describe --abbrev=0 --tags)"

GitLab CI логи выдают следующее

Fetching changes...
Removing assembly/target/
HEAD is now at 34ebda3 git reset --hard tag
From https://gitlab
   8d6b33c..1a4d902  master     -> origin/master
 * [new tag]         v1.0.74    -> v1.0.74
Checking out 34ebda34 as master...
Skipping Git submodules setup
Checking cache for master...
Successfully extracted cache
Downloading artifacts for build (12355)...
Downloading artifacts from coordinator... ok        id=12355 responseStatus=200 OK token=sMoApXN6
WARNING: assembly/target/: lchown assembly/target/: operation not permitted (suppressing repeats) 

$ git status
HEAD detached at 34ebda3
nothing to commit, working directory clean

$ git reset --hard $(git describe --abbrev=0 --tags)
HEAD is now at 1da6864 Release pom [ci skip]prepare release v1.0.72

$ git status
HEAD detached from 34ebda3
nothing to commit, working directory clean
$ docker login -u "$CI_REGISTRY_USER" -p $CI_JOB_TOKEN $CI_REGISTRY
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
WARNING! Your password will be stored unencrypted in /home/gitlab-runner/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store

Login Succeeded
$ docker build --pull -t "$CI_REGISTRY_IMAGE/$CI_PROJECT_NAME-$CI_COMMIT_REF_SLUG:$(git describe --abbrev=0 --tags)" .
Sending build context to Docker daemon  158.4MB

Step 1/5 : FROM docker-registry/java:8-jre
8-jre: Pulling from java
Digest: sha256:b91008e234402fc87e7889d6af1f36b6ece844c05989236d83d1f658a6f329b0
Status: Image is up to date for docker-registry/java:8-jre
 ---> e44d62cf8862
Step 2/5 : COPY XXXXXXXXX
 ---> 5f693fa6062d
Step 3/5 : WORKDIR XXXXXXXXX
 ---> Running in 351b6b37c6c1
Removing intermediate container 351b6b37c6c1
 ---> 5bf7d2fb6089
Step 4/5 : EXPOSE 8088
 ---> Running in 463d7158fb14
Removing intermediate container 463d7158fb14
 ---> 085a40b7f44a
Step 5/5 : CMD ["java", "-jar", "order.jar"]
 ---> Running in 95def8987caf
Removing intermediate container 95def8987caf
 ---> 9a7a7fdd0748
Successfully built 9a7a7fdd0748
Successfully tagged docker-registry/repository/XXXXXXXXX/XXXXXXXXX:v1.0.72

Видно что создается docker образ версии v1.0.72, а последняя версия - v1.0.74
Как вы выкачиваете последний git tag в Gitlab CI ?

Answer 1

[Антон Пацев]

Вот решение. Обновил после переписки с Георг

build_docker_container:
  stage: dockerize
  script:
    - git checkout master
    - git pull
    - export TAG_TO_BUILD=$(git describe --abbrev=0 --tags)
    - test -z "${TAG_TO_BUILD}" && echo "The TAG_TO_BUILD is empty" && exit 1
    - git reset --hard "${TAG_TO_BUILD}"
    - docker login -u "$CI_REGISTRY_USER" -p $CI_JOB_TOKEN $CI_REGISTRY
    - docker build --pull -t "$CI_REGISTRY_IMAGE/$CI_PROJECT_NAME-$CI_COMMIT_REF_SLUG:${TAG_TO_BUILD}" .
    - docker push "$CI_REGISTRY_IMAGE/$CI_PROJECT_NAME-$CI_COMMIT_REF_SLUG:${TAG_TO_BUILD}"

Comments

[Георг Гаал]

• небольшое улучшение: можно вынести вывод git describe в отдельную переменную
  
• насколько хорошо, что сборка производится не того тэга, который триггернул сборку, а последнего? Это может дать неочевидные конфликты в интерфейсе ГитЛаба, в остальном - вполне допустимо
  

[Антон Пацев]

Георг Гаал, А зачем выводить git describe в отдельную переменную?
И как получить тег, который триггернул сборку пока не нашел. Возможно у меня pipeline неправильный

[Георг Гаал]

Антон Пацев, насчет тега я же сказал:

CI_COMMIT_TAG или CI_COMMIT_REF_NAME / CI_COMMIT_REF_SLUG

рекомендую попробовать самостоятельно. Есть тонкость - принципиальной разницы между сборкой определенного бранча или определенного тега нет. Возможно, что это концептуально неверно и является недостатком. Т.е. при одновременном пуше, например, в ветку master и в tag v1.0.0, то стартанет ДВА пайплайна в одном CI_COMMIT_REF_NAME==master, а во втором CI_COMMIT_REF_NAME==v1.0.0.
Но можно разделить теги/бранчи с помощью ключевых слов в .gitlab-ci.yml

Еще момент

git describe в отдельную переменную?

в указанном примере git describe вызывается три раза.
Правильнее так:

- git checkout master
- git pull
- export TAG_TO_BUILD=$(git describe --abbrev=0 --tags)
- test -z "${TAG_TO_BUILD}" && echo "The TAG_TO_BUILD is empty" && exit 1
- git reset --hard
- docker login -u "$CI_REGISTRY_USER" -p $CI_JOB_TOKEN $CI_REGISTRY
- docker build --pull -t "$CI_REGISTRY_IMAGE/$CI_PROJECT_NAME-$CI_COMMIT_REF_SLUG:${TAG_TO_BUILD}" .
- docker push "$CI_REGISTRY_IMAGE/$CI_PROJECT_NAME-$CI_COMMIT_REF_SLUG:${TAG_TO_BUILD}"

[Антон Пацев]

По поводу CI_COMMIT_TAG или CI_COMMIT_REF_NAME / CI_COMMIT_REF_SLUG

Вот что они выдают

$ git tag
v1.0.73
v1.0.74
v1.0.75
v1.0.76
v1.0.77
v1.0.78
$ echo $CI_COMMIT_TAG

$ echo $CI_COMMIT_REF_NAME
master
$ echo $CI_COMMIT_REF_SLUG
master

Остальное да - хороший совет. Спасибо
только git reset --hard $(git describe --abbrev=0 --tags)

[Георг Гаал]

Антон Пацев, git tag выдает инфу, т.к. он берет информацию из репозитория.
CI_COMMIT_TAG - пустой, т.к. триггернута была сборка бранча мастер.
Если через веб-интерфейс тригернете сборку конкретного тэга, то сильно удивитесь.
Или создайте новый тэг через веб-интерфейс, или запушьте его в удаленный репо.

только git reset --hard $(git describe --abbrev=0 --tags)

да, прошу прощения. Вы поняли меня верно

Еще момент. В ТЕОРИИ pull'ить репозиторий по новой не нужно, т.к. gitlab автоматически клонит последнюю версию )))) Попробуйте посмотреть https://docs.gitlab.com/ee/ci/yaml/#git-strategy Возможно удастся оптимизировать сборку.

[Антон Пацев]

Если через веб-интерфейс тригернете сборку конкретного тэга, то сильно удивитесь.

Мы обычно через веб-интерфейс не тригерим сборку.
Обычно MR, commit

Answer 2

[Георг Гаал]

Я не совсем понял вопроса.

Дело в том, что Gitlab-CI это не про это.
Он для каждого нового tag (при создании через веб-интерфейс или при пуше в репо) создает новый пайплайн. Вытащить tag можно либо через переменную CI_COMMIT_TAG или CI_COMMIT_REF_NAME / CI_COMMIT_REF_SLUG

Если же тэг хранится в репозитории в файле, то можно его из него и вытащить (голову репозитория надо рассказать как спуллить?).

Comments

[Антон Пацев]

Нет. . Вытащить tag можно либо через переменную CI_COMMIT_TAG или CI_COMMIT_REF_NAME / CI_COMMIT_REF_SLUG - не работает

script:
    - git checkout master
    - git pull
    - git tag
    - echo $CI_COMMIT_TAG
    - echo $CI_COMMIT_REF_NAME
    - echo $CI_COMMIT_REF_SLUG

git tag
v1.0.76
v1.0.77
$ echo $CI_COMMIT_TAG

$ echo $CI_COMMIT_REF_NAME
master
$ echo $CI_COMMIT_REF_SLUG
master