Найти исходную ветку при создании тега в GitLab (используя gitlab-ci.yml) - PullRequest
0 голосов
/ 27 мая 2020

Сейчас я пытаюсь автоматически увеличить версию, добавить к ней SNAPSHOT и зафиксировать в ветке, что данный тег был создан с использованием GitLab 12.9.2 и GitLab-Shell 12.0.0.

Я знаю, что теги (особенно теги выпуска) должны создаваться из мастера, но, поскольку я могу получить ветку разработки или другие ветки, на которые я хотел бы пометить коммиты, я хотел сохранить возможность тегировать заданная фиксация, сборка, развертывание соответствующего артефакта (в Nexus), автоматическое увеличение версии (например, с 0.1.3 до 0.1.4-SNAPSHOT) и фиксация этого в ветке, из которой был создан тег .

В то время как все остальные шаги работают, я терплю неудачу на последнем, потому что я не могу найти правильную переменную среды, которая относится к фиксации (и ветви), из которой был создан тег.

Здесь является выдержкой из CI-файла:

build-release:
  extends: .build-template

  only:
    - tags

  before_script:
# Setup git
    - git config http.sslVerify false
    - git config user.email "git-bot@base/gitlab"
    - git config user.name "$GIT_CI_USER"
    - git remote set-url origin https://$GIT_CI_USER:$GIT_CI_PASSWORD@base/gitlab/development/particles/particles-front.git
    - git fetch
#    - git config http.sslCAInfo /etc/gitlab-runner/certs/base.crt ?
#    - git config http.sslCert /etc/gitlab-runner/certs/base.crt ? 

    - cd $CI_BUILDS_DIR/$SUB_PATH
# Install node_modules
    - npm install
# Show versions
    - node --version
    - npm --version
    - npm run ng version
# Save version for artifact-name
    - echo -n $CI_COMMIT_TAG > $CI_BUILDS_DIR/$SUB_PATH/version
# Set version back via npm in order to display it possibly on the user interface
    - npm version $(cat $CI_BUILDS_DIR/$SUB_PATH/version)

  after_script:
# Auto-Increment (patch-)version, append SNAPSHOT, commit & push
    - git checkout $CI_COMMIT_REF_NAME
    - cd $CI_BUILDS_DIR/$SUB_PATH
    - cat $CI_BUILDS_DIR/$SUB_PATH/version
    - npm version patch | cut -c 2-30 | tr -d '\n' > $CI_BUILDS_DIR/$SUB_PATH/version
    - echo -n -SNAPSHOT >> $CI_BUILDS_DIR/$SUB_PATH/version
    - npm version $(cat $CI_BUILDS_DIR/$SUB_PATH/version)
    - npm run prestart
    - git add ./package*.json ./src/_versions.ts
    - git status -sb
    - git commit -m "New Snapshot ($(cat $CI_BUILDS_DIR/$SUB_PATH/version))"
    - git push

Ошибка, которую я получаю (в последней команде, как видно в консоли вывода задания):

$ git push
fatal: You are not currently on a branch.
To push the history leading to the current (detached HEAD)
state now, use
    git push origin HEAD:<name-of-remote-branch>

Примечание : все работает нормально за исключением того, что фиксация в $CI_COMMIT_REF_NAME кажется плохой идеей, потому что она содержит только тег (в случае выше), но не фиксацию (и, следовательно, ветку), из которой был создан тег. Я говорю об этом конкретном значении здесь: New Tag creation dialog in GitLab.

Я читал различные другие вопросы SO, связанные с topi c (например, этот: Как мне pu sh в репо из конвейера Gitlab CI? ), но они, похоже, не решают мою проблему. Другое решение, использующее --points-at, кажется интересным, но я не знаю, как его использовать, чтобы решить мою проблему.

Любая помощь приветствуется!

1 Ответ

1 голос
/ 27 мая 2020

Мне нравится использовать полезный трюк: запускать команду printenv Linux из конвейерного задания. Это распечатает все переменные среды, включая встроенные переменные GitLab, в стандартный вывод. Затем вы можете просмотреть их и выбрать тот, который вам нужен.

Из того, что я вижу, вам могут помочь сообщения SHA фиксации или сообщение фиксации.

Использование SHA фиксации

  • CI_COMMIT_SHA
  • CI_COMMIT_SHORT_SHA = первые 8 цифр CI_COMMIT_SHA

CI_COMMIT_SHA относится к фиксации в ветке, из которой вы создали тег. Получив идентификатор фиксации, вы можете использовать GitLab REST API (например, используя cURL, python запросы или python -gitlab), чтобы получить необходимую информацию. Имейте в виду, что фиксация может принадлежать нескольким ветвям, поэтому вам нужно выяснить, на какую из них вы хотите нацелить.

curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/5/repository/commits/$CI_COMMIT_SHA/refs?type=all"
[
  {"type": "branch", "name": "'test'"},
  {"type": "branch", "name": "add-balsamiq-file"},
  {"type": "branch", "name": "wip"},
  {"type": "tag", "name": "v1.1.0"}
 ]

Чтобы узнать больше об информации, которую вы можете получить из commit SHA:

Использование сообщения фиксации

  • CI_COMMIT_MESSAGE = CI_COMMIT_TITLE + CI_COMMIT_DESCRIPTION
  • CI_COMMIT_TITLE
  • CI_COMMIT_TITLE *1038* *1039* CI_COMMIT_TITLE *1038* *1039* CI_COMMIT_TITLE *1038* *1039*

    Сообщение фиксации может помочь, если вы будете следовать определенному процессу c git. Например, это формат автоматически сгенерированных сообщений фиксации, когда автоматическое сжатие запроса на слияние фиксирует и объединяет ветвь функции с разработкой. Тег, из которого пришло это сообщение, был создан при разработке:

    Merge branch 'feature-branch-name' into 'develop'
    Merge request title
    See merge request group/project!123
    

    Примечание: первая строка - CI_COMMIT_TITLE, а последние 2 строки - CI_COMMIT_DESCRIPTION. CI_COMMIT_TITLE дает вам исходную ветку и целевую ветвь, тогда как CI_COMMIT_DESCRIPTION дает вам заголовок и идентификатор запроса на слияние. Вы можете получить практически всю необходимую информацию из MR ID с помощью GitLab REST API.

    Чтобы узнать больше о том, какую информацию вы можете получить из идентификатора запроса на слияние:

    К сожалению, если вы создаете тег из ветки функции, то COMMIT_MESSAGE дает вам только обычное сообщение о фиксации, написанное пользователем, который отправил фиксацию - вероятно, не очень интересно. COMMIT_DESCRIPTION в этом случае пусто, поэтому тоже бесполезно.

...