Обновления Gradle-release-plugin были отклонены, потому что верхушка вашей текущей ветки отстает

Question

На моем рабочем месте мы используем ежемесячную ветку выпуска, которая используется несколькими разработчиками.

Версия Gradle - 2.14.1

Мы вручную запускаем сборку и выпуск кода (задачу) с помощью Jenkins (который эффективен - gradle clean compile Java release)

Весь процесс занимает около 30-40 минут, в основном компиляция, генерация артефактов, запуск тестов Junit и загрузка артефактов в Artifactory.

В конце концов, дело доходит до тегирования и добавления номера версии: preTagCommit , который пытается обновить gradle.properties и увеличивает номер версии до него, а также фиксирует и отправляет.

На этом этапе, если в ветке не было никаких коммитов в течение последних 30-40 минут (так как сборка была запущена вручную), релиз работает успешно.

Момент есть хотя бы один совершить между всем процессом происходит сбой с ошибкой: Выполнение не выполнено для задачи ': preTagCommit'.

*
error: failed to push some refs to 'xxx.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
*

* 1 017 * Я попробовал несколько хаков и поискал в документации, но пока не нашел подходящего решения.

Вот как выглядит мой шаг выпуска:

***
    release {
        project.setProperty("gradle.release.useAutomaticVersion", "true");
        newVersionCommitMessage = "Re-snapshoted project to version "
        preTagCommitMessage = "Preparing version for release "
        tagCommitMessage = "Tagging Release "
        tagPrefix = "calypso"
        requireBranch = ""
        // Sometimes the plugin trips over its own feet with modifying the gradle.properties
        // then complaining it has changed.
        failOnCommitNeeded = false
        pushToCurrentBranch = true
    }
***

Извините, если об этом спрашивали ранее, все найденное мной решение было общим подходом к git, а не от кого-то, использующего Gradle -Release-Plugin с git.

Мы будем благодарны за любой ответ.

Answer 1

Я считаю, что флаг, который вы ищете, упоминается на странице GitHub плагина:

Например. Чтобы игнорировать изменения восходящего потока, измените 'failOnUpdateNeeded' на false:

release {
  failOnUpdateNeeded = false
}

---

Edit

Похоже, что указанный выше флаг не работает по какой-то причине. Тем не менее, есть еще один способ сделать это sh, а именно добавить опцию принудительного действия sh к опции git расширения release (что за глупость) .

release {
  git {
    pushOptions = ['--force']
  }
}

Это в основном приведет к принудительной перезаписи ветки (см. анализ проблем ниже), если только сервер, на котором размещен репозиторий, не настроен на отклонение таких принудительных нажатий. В этом случае здесь действительно нет варианта, который поможет.

---

Анализ проблемы

Как я сказал в моем последнем комментарии ниже, часть, которая терпит неудачу, - это когда extension запускает задачу preTagCommit, а затем пытается сделать sh эту фиксацию в восходящей ветке (например, master). Вы можете увидеть эту команду pu sh справа здесь .

Ну, конечно, это не удастся, если кто-то уже отправил фиксацию в эту ветку.

Теперь проще способ исправить это было бы, если бы авторы плагина дали нам возможность сказать

Don't pu sh preTag коммитирует апстрим

или

Pu sh preTagCompts к ветке с именем foo

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

Решения / Хаки

Укажите pushToBranchPrefix Создайте ветку с тегами

Это - это еще один параметр , который может быть передан объекту git, что приводит к тому, что все нажатия, которые он делает, выполняются в определенной ветке c с заданным префиксом, а не в текущей ветке:

Например:

afterReleaseBuild {
  doFirst {
    project.exec {
        executable = 'git'
        args 'checkout', '-b', 'v1.x.x@master'
    }
  }
}

Замените v1.x.x чем-то, что соответствует тегу для текущего выпуска.

Это означает, что всякий раз, когда плагин пытается нажать / зафиксировать , он вместо этого отправит / зафиксирует эту ветку, которую мы создали, и, наконец, создаст тег из этой ветки. 1075 *

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

tasks.named('preTagCommit') {
    enabled = false
}

Определите для себя, приемлемо ли это.

Динамика c пу sh поведение

Поскольку я видел исходный код, я могу увидеть , что причина, по которой он нажимает, заключается в том, что он видит, что git.pushToRemote не является нулевым. Зная это, мы можем динамически управлять этим поведением.

tasks.named('preTagCommit') {
  def pushToRemote = null
  doFirst {
    project.extensions.configure(net.researchgate.release.ReleaseExtension) {
      pushToRemote = it.git.pushToRemote
      it.git.pushToRemote = null
    }
  }

  doLast {
    project.extensions.configure(net.researchgate.release.ReleaseExtension) {
      it.git.pushToRemote = pushToRemote
    }
  }
}

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

Answer 2

Самым простым выходом в моей ситуации было просто изменить компонент моего релизного плагина в build.gradle:

***
release {
....
 pushToRemote = ''
....
}
***

Это гарантирует, что релизный плагин не будет pu sh!

После того, как управление поступает из выпуска gradle, я добавил:

Git pull origin

Git pu sh --tags origin

Это прекрасно синхронизировало мои коммиты, а также следует правилу pull before pu sh!

Хотя это хакерское решение, @Clijsters предложил мне использовать специальные ветки выпуска для решения этой проблемы.