Wrong branch is used with GIT_STRATEGY=clone
kvandake opened this issue · comments
При добавлении второго аргумента $branch пуш не происходит.
Ниже логи
$ git-push dokku@dokku.me:dev $CI_COMMIT_REF_NAME
# dokku.me:22 SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
# dokku.me:22 SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
# dokku.me:22 SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2
Warning: Permanently added the ECDSA host key for IP address 'XX.XX.XX.XXX' to the list of known hosts.
To dokku.me:dev
769ba3a..42eafbd HEAD -> develop
Job succeeded
Также я пробовал добавлять вместо $CI_COMMIT_REF_NAME конткретные ветки(develop, staging) - результат аналогичный.
Прикладываю отрывок от gitlab-ci.yml
# region Deploy
deploy_develop:
stage: deploy
image: ilyasemenov/gitlab-ci-git-push
variables:
SSH_PRIVATE_KEY: $DEV_SSH_PRIVATE_KEY
script: git-push dokku@dokku.me:dev $CI_COMMIT_REF_NAME
only:
- develop
Что значит "пуш не происходит"? В твоих же логах написано:
To dokku.me:dev
769ba3a..42eafbd HEAD -> develop
это самый что ни на есть успешный пуш в удалённый репозиторий, в ветку develop.
Возможно, ты перепутал удаленные ветки и удаленные pass приложения. dokku, к примеру, обрабатывает пуши только в ветку master. В другие ветки технически тоже можно пушить на уровне гита, только это ничего не дает (не вызывает обновления приложения).
То есть, условно, должно быть не git-push dokku@dokku.me:dev $CI_COMMIT_REF_NAME
, а git-push dokku@dokku.me:myapp-${CI_COMMIT_REF_NAME}
(где myapp-develop
должно быть, конечно, заранее создано).
в Dokku мастер тригерная ветка для деплоя. У меня в вышеприведенном примере создавалась на Dokku ветка develop, что и не давало никакого эффекта.
Dokku, как и Heroku, разрешает деплоить non-master ветки.
Поэтому в моем случае сработало вот так:
if [ -z "$branch" ]; then
branch="master"
fi
git checkout $branch
git push $url $branch:master $([ -z "$DISABLE_FORCE_PUSH" ] && echo --force)
Это очень странно. Сейчас так:
git push $url HEAD:${branch:-master} $([ -z "$DISABLE_FORCE_PUSH" ] && echo --force)
ты говоришь, что это не работает, но работает если заменить HEAD
на $branch
:
git push $url $branch:master $([ -z "$DISABLE_FORCE_PUSH" ] && echo --force)
правильно я понимаю?
но HEAD в gitlab-ci-runner всегда указывает на текущий коммит (для которого он вызвался). при коммите/пуше в ветку он будет указывать на эту ветку, поэтому замена HEAD
на $branch
бессмысленна. Я только что это проверил:
Running with gitlab-ci-multi-runner 9.5.1 (96b34cc)
on sys (2348cc87)
Using Docker executor with image ilyasemenov/gitlab-ci-git-push ...
Using docker image sha256:96d74ee76f6bfb4665a213a6b083a08ed843fa7275be6cacfb81cc3d7d5b0f6e for predefined container...
Pulling docker image ilyasemenov/gitlab-ci-git-push ...
Using docker image ilyasemenov/gitlab-ci-git-push ID=sha256:74454907e1294ab25ab1b4dd96f3668fbc7995958e72b48270b93960f6400ad9 for build container...
Running on runner-2348cc87-project-112-concurrent-0 via sys...
Fetching changes...
HEAD is now at ebf5264 initial commit
From https://git.inetss.com/semenov/gitlab-ci-test
* [new branch] br1 -> origin/br1
Checking out cf29088d as br1...
Skipping Git submodules setup
$ echo HEAD is $(git rev-parse HEAD)
HEAD is cf29088d37f67903403e4a54cd7d2e2367b854ce
Job succeeded
Видно, что HEAD указывает на запушенный коммит в ветке br1
.
Единственный случай, когда HEAD не будет указывать на коммит из нужной ветки, это если ты используешь GIT_STRATEGY=clone
и GIT_CHECKOUT=false
(https://docs.gitlab.com/ce/ci/yaml/README.html#git-checkout), тогда в gitlab-ci-runner каждый раз делается clone и он указывает на дефолтную ветку. (Либо, возможно, у тебя очень старый gitlab-ci-runner.)
Для поддержки такого случая, видимо, имеет смысл HEAD
заменить на ${CI_COMMIT_REF_NAME}
, чтобы точно было надежно. Но делать checkout это лишнее.
Проверил, при GIT_STRATEGY=clone
и GIT_CHECKOUT=false
HEAD
действительно указывает всегда на мастер и пуш происходит не из текущей ветки, а из мастера. При этом использование $CI_COMMIT_REF_NAME
дает fatal: ambiguous argument 'br1': unknown revision or path not in the working tree.
, а вот $CI_COMMIT_SHA
работает. Сейчас поправлю.
Спасибо!