Тег GitLab Pipeline прекратил запуск только помеченного этапа: теги

Question

У нас есть конвейер GitLab, который запускается из другого конвейера. Этот конвейер состоит из двух этапов, каждый из которых выполняется в отдельном экземпляре конвейера. Обе эти ступени работают правильно.

Первая ступень реагирует на триггер. Он находит тег версии в репозитории, увеличивает его на единицу и применяет этот тег обратно к текущему проекту.

Второй этап выполняется в ответ на новый тег в новом экземпляре конвейера. Этот этап также отлично работает при запуске.

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

РЕЗЮМЕ ПРОБЛЕМЫ

• Если вы используете триггер, который запускает этап 'createtag', этап 'createtag' запускается, создает тег, подталкивает его к репо, а затем к этапу «развертывания» только: теги не запускаются. Но раньше, до двух недель, go.

ТРУБОПРОВОД ИСПОЛЬЗУЕТСЯ НА ДРУГИЕ МЕТОДЫ УСТАНОВКИ ТЕГ

• Если вы создаете тег из GIT командная строка и pu sh в репозиторий, стадия «развертывания» только с тегами работает.
• Если вы создаете тег на главной странице проекта GitLab через Create New | Новая опция раскрывающегося списка тегов, этап «развертывание» только с тегами:

ОДИН ДРУГОЙ БИТ КЛЮЧЕВОЙ ИНФОРМАЦИИ

Этап 'createtag' также перестал работать две недели go. Оказывается, токен, связанный с триггером, недействителен, и пользователь, которому принадлежал токен, больше не был в компании, и GitLab показывал «Заблокировано» рядом с пользователем на вкладке «Участники».

Принятие на себя владения Триггер / токен с текущим пользователем повторно активировал токен. После этого этап createtag снова запустился. Проблема в том, что этап 'deploy' по-прежнему не запускается, когда этап 'createtag' помещает новый тег в репозиторий.

Любые идеи о том, что произошло и как запустить этап "deploy" снова реагировать на действия стадии 'createtag'? Я вполне уверен, что это связано с разрешениями для пользователя, который ушел.

variables:
    CI_DEBUG_TRACE: "true"

stages:
  - createtag
  - deploy

# When receiving a trigger to build, tag the repository with the next numeric
# build version. This should kick off the next build pipeline for deployment.
increment_version:
  stage: createtag
  script:
    # For brevity, logic to connect to repo, get tags, set $NEW_TAG are omitted. They work just fine

    # Create new tag and push to repo
    - git tag $NEW_TAG master
    - git push --tags

  only:
    - triggers

# When a tagged build is received, execute script
deploy_to_somewhere:
  stage: deploy
  script:
    - [Do Something Here]
  only:
    - tags

Answer 1

Я экспериментировал со следующим .gitlab-ci.yml, чтобы посмотреть, смогу ли я получить задание пометить сборку, которая затем вызовет другой экземпляр того же конвейера; и следующее делает это (с отредактированным токеном личного доступа).

Мне пришлось добавить токен триггера и токен личного доступа, чтобы этот тест работал.

Это сработало, как и ожидалось - Я бы нажал на конвейер с помощью curl, чтобы запустить его, а затем он создал бы тег, и это вызвало бы другой конвейер, который запустил бы развертывание.

Вот полная рабочая .gitlab-ci.yml:

createtag:
  script:
    - git config --global user.email "me@example.com"
    - git config --global user.name "My Name"
    - git tag -m 'tag message' $(date +%s) origin/master
    - git remote add mygitlab https://oauth2:__MYTOKEN__@gitlab.com/atsaloli/trigger-test.git
    - git push --tags mygitlab
  only:
    - triggers

deploy_to_somewhere:
  script:
    - echo run deploy script
  only:
    - tags

и снимок экрана, показывающий два экземпляра конвейера:

Итак, то, что вы описали, может определенно работать - я бы Посмотрите немного поближе на свою систему, чтобы увидеть, работает ли каждая часть как следует - например, команды git, которые вы дали, я не вижу, как они будут работать ...

Где у вас есть :

  # Create new tag and push to repo
    - git tag $NEW_TAG master
    - git push --tags

Я обнаружил, что у меня не работает.

Сначала «мастер» не был известен git ссылка:

 $ git tag $(date +%s) master
 fatal: Failed to resolve 'master' as a valid ref.

Затем «происхождение / мастер» сработало, но мне пришлось установить свою личность:

 $ git tag -m 'tag message' $(date +%s) origin/master
 *** Please tell me who you are.
 Run
   git config --global user.email "you@example.com"
   git config --global user.name "Your Name"
 to set your account's default identity.
 Omit --global to set the identity only in this repository.
 fatal: unable to auto-detect email address (got 'root@runner-72989761-project-3569621-concurrent-0.(none)')

Наконец, я должен был предоставить gitlab-ci-token:

 $ git config --global user.email "me@example.com"
 $ git config --global user.name "My Name"
 $ git tag -m 'tag message' $(date +%s) origin/master
 $ git push --tags
 remote: You are not allowed to upload code.
 fatal: unable to access 'https://gitlab-ci-token:[MASKED]@gitlab.com/atsaloli/test.git/': The requested URL returned error: 403

Так что, как только я обработал все это, я обнаружил, что могу автоматически пометить репо, что приведет к другому экземпляру трубопровод для запуска.