плагин релиза maven для простого проекта git - ошибка: не рабочая копия - PullRequest
Новая
       7

плагин релиза maven для простого проекта git - ошибка: не рабочая копия

0 голосов
/ 12 января 2019

Как я могу выполнить 'release' в простом проекте, используя Maven 'maven-release-plugin' при использовании с Git (lab)?

Я работаю над веткой dev / feature и, наконец, объединяю обновления в ветку 'master'. Я думаю, тогда плагин «релиз» вступает в игру. Правильный?

В моем Jenkinsfile я звоню: 

sh 'mvn release:prepare release:perform'

Пробуя много вариантов, я получаю эту ошибку: 

The svn command failed. 
[ERROR] Command output:
[ERROR] svn: E155007: '..workspace/project/pom.xml' is not a working copy

Сбой команды: 

[INFO] Executing: /bin/sh -c cd /var/jenkins_home/workspace/jenkins-testing-releasing && svn --non-interactive commit --file /tmp/maven-scm-1557766606.commit --targets /tmp/maven-scm-8208798121252708517-targets
[INFO] Working directory: /var/jenkins_home/workspace/jenkins-testing-releasing

Странно, потому что я не работаю с SVN.

Это то, что я имею до сих пор: 

<project ...
    <artifactId>jenkinstesting</artifactId>
    <version>0.1-SNAPSHOT</version>
    <scm>
        <connection>scm:git:git@gitlab.com:user/project.git</connection>
        <developerConnection>scm:git:git@gitlab.com:user/project.git</developerConnection>
        <tag>rel1</tag>
    </scm>

Версия 1: 

    <build>
        <plugins ... 
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-release-plugin</artifactId>
                <version>2.2.1</version>
                <executions>
                    <execution>
                        <id>default</id>
                        <goals>
                            <goal>perform</goal>
                        </goals>
                        <configuration>
                            <pomFileName>pom.xml</pomFileName>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

Версия 2: 

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>versions-maven-plugin</artifactId>
    <version>2.1</version>
</plugin>
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-release-plugin</artifactId>
    <version>2.5.3</version>
</plugin>

1 Ответ

0 голосов
/ 17 января 2019

Как предлагается в некоторых сообщениях, (действительно) лучше использовать плагин Jgitflow Maven. Даже проект изменился на этот плагин. Таким образом, не было никакой причины придерживаться плагина Maven Release. Оглядываясь назад, Я наконец согласен с советом и продолжаю работу с плагином Jgitflow.

Каковы результаты этапа выпуска? Предположим, что текущая версия ветки разработки - 0.5.0-SNAPSHOT.

  • У нас есть ветка 'release' с правильной версией и встроенными продуктами (v0.5.0);
  • У нас есть ветка 'development', готовая к следующему выпуску (v0.6.0-SNAPSHOT);
  • В качестве резервной копии у нас есть ветка 'master' (v0.5.0).

Какие действия требуются?

  • Создайте новую ветку 'release' на основе ветки разработки. Версия этой ветки является текущей версией минус часть '-SNAPSHOT'.
  • Создайте конечные продукты с этой веткой выпуска. Вы также можете создавать образы Docker с тегом с этой версией. Вы можете добавить другие метки к этому изображению Docker.
  • Слить ветку в ветку 'master'. Таким образом, у вас есть резервная копия для производственных проблем.
  • Определить номер следующей версии ветки 'development'. Это зависит от того, хотите ли вы выпуск майора, минора или патча.
  • Обновите ветку 'development' новой версией.

ОК, покажи мне код ...; -) 

def mavenHome = tool 'Maven Latest'
def nextVersion = // determine this on the requested major/minor/patch release
sh "${mavenHome}/bin/mvn clean -B jgitflow:release-start jgitflow:release-finish " +
        "-DskipTests " +
        "-DallowUntracked=true " +
        "-DpushReleases=true " +
        "-DscmCommentPrefix=[RELEASE]- " +
        "-DenableSshAgent=true " +
        "-DreleaseVersion=${nextVersion}"

Определение следующей версии может принимать в качестве аргумента: мажор, минор или патч и т. Д.

Подготовка: при работе с GIT-потоком вы можете объединить изменения вашей функциональной ветви с веткой разработки с помощью запроса на извлечение.

...