Почему TeamCity при rebase git собирает заново коммиты, которые уже собрал раньше?
Собственно вопрос.
Если сделать git rebase, ТС почему то думает что заехали новые коммиты. И ставит их в очередь.
Поэтому если девер работал над веткой месяц, а потом сделал ребэйз, то очередь моментально заполняется сотней другой билдами. Что уже печаль. А если таких веток одновременно выкладывается несколько - печаль многократная. А еще и каждый билд по несколько (пока) минут.
Хотя по истории видно, что эти коммиты и мерджи он уже собирал.
В гугле советовали снять галку в Triggers - VCS Trigger - Per-checkin Triggering - "Include several checkins in a build if they are from the same commiter".
Но это не помогло, насколько я понимаю галка отвечает за то, чтобы от одного коммитера (девера) собирался один билд, несмотря на несколько коммитов - что собственно должно немного ускорить процесс.
Снимать галку "Trigger a build on each check-in" тоже не хочется, так будет видно кто накосячил - ибо проект очень быстро растет и наполняется людьми, которые косячат ))
В качестве git стоит Bitbucket. Так же стоит ограничение на мердж без зеленого билда.
Вот не могу понять, что за дикость такая? я понимаю что гиту пофиг, накидал коммитов по своим правилам. Но почему ТС не отслеживает это?
Как это? ведь судя по ревизии этот коммит уже существовал в другой ветке, и он уже сбилдился.
По сути рояли не играет, призвать разрабов не делать rebase не получится, да и не правильно это как-то.
Роман: Ребейз переписывает историю. Сообщение тоже самое, содержание тоже самое, автор и дата создания те же. Предок и хеш - другие. Для git и для TC это совершенно другой коммит.
"да и не правильно это как-то."
Есть много мнений. Одно из (которого и я придерживаюсь) - неправильно ребейзить. Все ребейзы должны быть локальными. Если коммит был отправлен на сервер, то ребейзить его нельзя.
Роман: И вообще, представьте ситуацию, что у вас нет этой проблемы, и ТС определяет ребейз.
2 разработчика делают параллельно 2 фичи. ТС их сбилдил, прогнал тесты. Все ок. Одна ветка вмержится в мастер (пусть в мастере не было изменений, тут ff мерж).
А затем вторая ветка ребейзится на мастер. Но вот незадача. Первый разработчик поменял поведение функции, которую использовал второй. И теперь вторая фича неправильно работает и тесты не проходит. Но ТС будет молчать, потому что он уже когда-то проверял эти коммиты, хоть их поведение и поменялось с того раза.. Как вам такой расклад?
Так, давайте по-порядку.
1. Как это хэш другой?
Захожу в ТС, мне пишет что в ветке 100500 изменений. Смотрю коммит в середине, иду в git и нахожу такой коммит и тадам - он билдился 10 дней назад в другой ветке (?) Т.е. хэши старых коммитов не изменились в новой ветке.
Еслибы хэш коммита(старого!) был бы свежий - я бы понял, т.к. ТС его не билдил то все ОК. Но он же существует?
Насчет ребейза локально не совсем понял. как это локально?
Есть подозрения что на мердж так же ТС реагирует, если долго не мержился. Точно подтвердить не могу, ибо надо накопить такой объем чтобы проверить.
Насчет ребейза на мастер. Второй чел на ребейзе должен уже увидеть, что с мастера заехали свежие коммиты к нему, и все развалилось. Иначе мерж не должен пройти. Разве нет?
Как я понимаю ребейз: все обнуляется до начала ветки, и далее по очереди вкатываются коммиты с основной ветки и твои по датам(?), короче по мере появления. Так вот старые коммиты то уже собранные (билд).
Суть в том, что ТС кидает коммиты в билд, но эти коммиты уже собирались, т.е. сборка на момент хэша коммита есть(была?). От того что в другой ветке соберется билд по этому же хэшу, ничего не измениться. Ведь на момент хэша код будет один и тот же. Или нет?
Я примерно понял о чем вы - т.к. предок ветка другая, слив со старым коммитом будет новый хэш. с точки зрения механики все так. Но с точки зрения билдов ТС, как я описал выше, это не есть гуд.
Если и ребейз и мердж делают такие выкидоны - как жить дальше?
Роман: "Иначе мерж не должен пройти. Разве нет?"
Не путайте конфликты слияния и логические ошибки.
Один разрабочик писал код с условием, что функция f возвразает всегда 0. А другой изменит её, что бы она возвращала всегда 1. Естественно git сольёт без ошибок. Но код одного из разработчиков после ребейза будет делать совсем не то.
Простой
Сложный
