Jenkins, freestyle job and git commit

Если требуется внести какие-либо изменения в гит ветку через jenkins, у нас есть плагин Git Plugin. Но он хорошо работает только если нам не нужны правки в репе, потому что суть плагина в том что он делает "detached HEAD", через получение id последнего коммита в ветке и git checkout (id), получая тем самым этот detached.
При этом мы можем сделать в сборке коммит (но не можем push - запросит данные для авторизации в гите), а дальше в послесборочных операциях добавляем Git Publisher, который вроде как пушит.. но всё пропадает бесследно. Также проблем добавляет то, что описания (те что в дженкинсе по нажатию вопроса) писал имбецил, из них непонятно ничего. Прежде всего речь про git publisher - branches.
Рекомендуется в Additional Behaviours добавить Clean before checkout
И до начала убеждаемся, что у нас есть права на push, иначе можно очень долго тупить когда будет говорить repository not found.

Что нужно проверить.
В управлении исходным кодом стоит refs/heads/our_branch
В Additional Behaviours добавлено
1) Clean before checkout
2) Custom user name/e-mail address и заполнено
3) Check out to specific local branch - commitbranch (имя можно поставить своё, это временная ветка, если первый пункт не ставить то в имя добавить $BRANCH_ID)
Таким образом, detached HEAD у нас превращается в локальную ветку, с которой гораздо проще работать.

Для успешного пуша необходимо в Branches - add branch добавить ветку,
Branch to push - имя ветки куда мы будем пушить, без префиксов, если пушить надо туда же откуда делали чекаут то нужно распарсить $GIT_BRANCH, взяв только последнюю секцию (без origin/ или refs/heads/), например так ${GIT_BRANCH/refs\/heads\//}
Target remote name - origin

Но есть и "другие варианты"
Итак, вариант первый: в build добавляем
git checkout $GIT_BRANCH и будет нормальный чекаут
https://stackoverflow.com/questions/19922435/how-to-push-changes-to-github-after-jenkins-build-completes/29786580
(но с пушем по прежнему есть нюансы, читаем по ссылке)

Вариант второй: сделать временную ветку и потом мержить её в нужную нам
Additional Behaviours - Check out to specific local branch
commitbranch-$BRANCH_ID
по сути, выше это и описано

Вариант третий:
Пушить не через git publisher а из шелла. Привет проблемы с тем как передать авторизацию, надо читать про git_askpass
https://stackoverflow.com/questions/42627269/jenkins-using-git-askpass-to-set-credentials/42636309
и в общем самый костыльный вариант

И ещё можно почитать
https://riptutorial.com/jenkins/example/27915/configuring-the-auto-push-job
https://stackoverflow.com/questions/14766214/jenkins-git-publisher-how-to-push-back-to-git-branch
https://www.theserverside.com/video/Tips-and-tricks-on-how-to-use-Jenkins-Git-Plugin

github deploy keys

Работали долгое время с битбакетом, но на другом проекте используют github.
https://developer.github.com/v3/guides/managing-deploy-keys/#deploy-keys
Делаем по инструкции, добавляем ключ для деплоя на одну репу, работает. Добавляем на другую - получаем ошибку
Error: Key already in use

Эти идиоты не осилили 1 деплой ключ на несколько реп! При том что битбакет так умеет, а гитлаб вообще штатно предлагает список уже подключенных ключей, для ещё бОльшего удобства. И это при том что если завести "фейкового" юзера, которому навесить тот же ключ и через запрос invitation выдать доступы то всё работает. Так что это именно рукожопость и ничего более.

Разные варианты гуглятся по "github Error: Key already in use"

5 решений:

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

2) через ssh-keygen (можно в интерактивном режиме) создаём столько ключей, сколько у нас реп, заводим где-то табличку с публичными ключами и от чего они. Теперь можно заполнить ~/.ssh/config, вписав несколько Host секций с разными IdentityFile, и делать git clone по этим именам,
3) или выставляя переменную - в 2.10+ есть GIT_SSH_COMMAND куда передаем строку вида 'ssh -i ~/.ssh/key1', в более ранних нужно возиться через врапперы и выставлять переменную так: GIT_SSH='~/git_wrapper.sh', в котором будет
ssh -i '~/.ssh/key1' $1 $2
4) ssh_agent
5) сменить площадку на битбакет или гитлаб, где нет этого маразма.

Более развернуто например тут
https://superuser.com/questions/232373/how-to-tell-git-which-private-key-to-use

git clone: github+2FA

Суть в том, что при использовании https после ввода пароля (правильного) будет ошибка

remote: Invalid username or password.

Причина:

https://help.github.com/articles/accessing-github-using-two-factor-authentication/#authenticating-on-the-command-line-using-https

"After you've enabled 2FA, you must create a personal access token to use as a password when authenticating to GitHub on the command line using HTTPS URLs."

Ну или более простой вариант - добавить ssh ключ

https://github.com/settings/keys

и потом делать git clone git@github.com:/user/repo

bup - backup system based on git

Very efficient backup system based on the git packfile format, providing fast incremental saves and global deduplication (among and within files, including virtual machine images).

https://github.com/bup/bup

В центоси легче всего поставить так:
1) либы
yum install python python-devel
yum install fuse-python pyxattr pylibacl
yum install perl-Time-HiRes

2) скачать сам пакет
http://dl.fedoraproject.org/pub/fedora/linux/releases/26/Everything/x86_64/os/Packages/b/bup-0.29-2.fc26.x86_64.rpm

3) rpm -Uvh bup*

4) используем.
Initialize the default BUP_DIR (~/.bup):
 bup init

Make a local backup (-v or -vv will increase the verbosity):
 bup index /etc
 bup save -n local-etc /etc

Restore a local backup to ./dest:
 bup restore -C ./dest local-etc/latest/etc
 ls -l dest/etc

Для пропуска некоторых файлов у index есть опции
--exclude
--exclude-from

Чтобы указать рабочий каталог отличный от ~/.bup, можно сделать так
export BUP_DIR=/backup/bup/...

git и bitbucket = беспарольная работа

Сделали клон какого-то репозитария, и активно с ним работаем, но ввод пароля утомляет. Что делать? Можно настроить беспарольный вход по ssh ключам.

1) создадим ключи. Делаем от того пользователя, от которого будем работать, то есть не рута.

ssh_keygen -b 2048 -N '' -f ~/.ssh/bitbucket
cat >> ~/.ssh/config <<EOF
Host bitbucket.org
  User git
  IdentityFile ~/.ssh/bitbucket
EOF

chmod 0600 ~/.ssh/config
cat ~/.ssh/bitbucket.pub

2)
вывод - на битбакет (публичный ключ), раздел настройки (manage) - security - SSH keys - add key
User git - не меняем, так и должно быть, актуальный юзер указывается в пути.

Если надо сделать ключ для деплоя (только для чтения), то добавляется он в другое место - открываем репозиторий, слева внизу settings, там в Deployment keys придумываем имя ключа (оно же будет логином) и вставляем ключ, полученный выше.

3) проверка
ssh -T git@bitbucket.org

Если что-то не так, можно руками добавить после -T: -i (какой файл использовать)

Нормальный вывод:
authenticated via a deploy key.


You can use git or hg to connect to Bitbucket. Shell access is disabled.

This deploy key has read access to the following repositories:

и дальше список, куда можно логиниться. Смотрим интересующие нас репы и копируем/запоминаем первую часть до двоеточия (:), понадобится дальше.

4) Использование

git clone ssh://git@bitbucket.org/(тут пишем/вставляем нужную репу, выбранную выше)

хотя если в .ssh/config есть User git, то из клона можно убрать git@

Линки
https://confluence.atlassian.com/display/BITBUCKET/Add+an+SSH+key+to+an+account
https://confluence.atlassian.com/display/BITBUCKET/Set+up+SSH+for+Git
https://confluence.atlassian.com/display/BITBUCKET/Use+deployment+keys
http://jeka.by/post/1051/setup-ssh-keys-for-bitbucket-github/ - с картинками

Everyday Git Aliases

http://code.joejag.com/2013/everyday-git-aliases/

Только непонятно, шутка это или просто неудачно выбранное число - 1 апреля.

Mercurial vs Git

Ещё раз о «Mercurial против Git» (с картинками)
Сходство и различие между Mercurial и Git
Проект Xen перешёл с Mercurial на Git

Ну и как всегда, 80% полезной инфы там в комментах.

git: post-receive hook

При попытке реализовать хук в гите на post-receive, сначала постоянно будет лезть ошибка
error: git-shell died of signal 13
fatal: The remote end hung up unexpectedly
error: error in sideband demultiplexer

Дело в том, что данный хук сделан каким-то извращенцем, поэтому аргументы хуку передаются через stdin и единственно верный (официально) метод чтения (для sh):

while read oldrev newrev refname
do
...
done

На другие языки переписать по аналогии.

И попутно заметка: если был коммит в мастер, запустить ssh

#!/bin/sh
while read oldrev newrev refname
do
        if expr "$refname" : '.*master$' >/dev/null; then
                ssh user@server.local /var/www/site/up
        fi
done

Основы работы с git

Основные постулаты работы с кодом:

• Каждая задача решается в своей ветке.
• Коммитим сразу, как что-то получили осмысленное.
• В master мержится не разработчиком, а вторым человеком, который производит вычитку и тестирование изменения
• Все коммиты должны быть осмысленно подписаны.
• Репозиторий должен держаться сухим и шелковистым

Инструкция-шпаргалка для начинающих

Git Wizardry. Азы.

Плюс настройка gitolite