Integration with Jenkins Release Plugin

[ajeans]

I am using gradle-release at version 2.6.0 with a Git project. Releasing either locally or with Jenkins works fine when doing the standard gradle -Prelease.useAutomaticVersion=true -Prelease.releaseVersion=$REL_VERSION -Prelease.newVersion=$DEV_VERSION

However, to improve my Jenkins jobs, I would like to use the Jenkins release plugin (see https://wiki.jenkins.io/display/JENKINS/Release+Plugin) along with the gradle release plugin. This means that when releasing the job, the gradle release plugin would be called before the actual build with some tasks, and called again after the actual build with some other tasks.

This doesn't seem to be a common request and I didn't find any documentation about it. The best configuration I could come up with on my own was:

• before the build, gradle runs with "createScmAdapter initScmAdapter checkCommitNeeded checkUpdateNeeded unSnapshotVersion confirmReleaseVersion checkSnapshotDependencies"
• after the build, gradle runs with "createScmAdapter initScmAdapter preTagCommit createReleaseTag updateVersion commitNewVersion"

This almost works but the preTagCommit is missing when doing the release this way. This is because preTagCommit() depends on internal plugin state set by the previous unSnapshotVersion task to decide if it needs to do a commit before the tag. But as unSnapshotVersion() is done in a previous gradle execution, the preTagCommit logic is simply skipped.

Is there a way to achieve this?

[ajeans]

Specifically, I was thinking of adding a configuration knob such as "forcePreTagCommit" that would default to false. I could then add this knob to the "if" condition in preTagCommit.

    void preTagCommit() {
        if (attributes.usesSnapshot || attributes.versionModified || attributes.propertiesFileCreated || extension.forcePreTagCommit) {
            // should only be committed if the project was using a snapshot version or if the configuration says to always commit before the tag.

Would you take such a patch? I could create a PR with that change...

[Hillkorn]

Hey, if I understand you right you want to have seperate tasks for the release process like unsapshot then build and then next version set? As you jenkins job works better this way? And it already works with the release plugin of jenkins or do you have trouble with it?

[ajeans]

Hello, Yes you understood correctly. The Jenkins Release Plugin lets Jenkins users define only one Jenkins job with all the build definitions, and some extra configuration / triggers before and after that when the release is activated. Without this Jenkins plugin, the alternative is to set up two Jenkins jobs, one for build (e.g. "gradle build") and one for release (e.g. "gradle release -P..."). And build configuration is duplicated across the two jobs.

It almost works for us with the configuration I wrote down in the description, but the commit before the tag is missing because of the logic in preTagCommit. So basically, the tag is done on the previous SNAPSHOT version rather than on the release version.

Hence my idea of an additional knob to force the pre tag commit.

[Hillkorn]

Hm we also used the jenkins release plugin and had only 1 job that does both. Sadly we don't use it anymore that i could look it up easily but let me check if I find it.

[Hillkorn]

We just added a preBuildStep only and used this to create the release.

[ajeans]

Not sure I follow, what did you do in the preBuildStep?

[Hillkorn]

Our config was like

<hudson.plugins.release.ReleaseWrapper plugin="release@2.8">
        <releaseVersionTemplate>Release: ${releaseVersion}</releaseVersionTemplate>
        <doNotKeepLog>true</doNotKeepLog>
        <overrideBuildParameters>false</overrideBuildParameters>
        <parameterDefinitions>
          <hudson.model.StringParameterDefinition>
            <name>releaseVersion</name>
            <description></description>
            <defaultValue></defaultValue>
          </hudson.model.StringParameterDefinition>
          <hudson.model.StringParameterDefinition>
            <name>nextSnapshotVersion</name>
            <description></description>
            <defaultValue></defaultValue>
          </hudson.model.StringParameterDefinition>
        </parameterDefinitions>
        <preBuildSteps>
          <hudson.plugins.gradle.Gradle plugin="gradle@1.28">
            <switches></switches>
            <tasks>clean --refresh-dependencies -Pgradle.release.useAutomaticVersion=true  -PnewVersion=${nextSnapshotVersion} -PreleaseVersion=${releaseVersion} release </tasks>
            <rootBuildScriptDir></rootBuildScriptDir>
            <buildFile></buildFile>
            <gradleName>(Default)</gradleName>
            <useWrapper>false</useWrapper>
            <makeExecutable>false</makeExecutable>
            <useWorkspaceAsHome>false</useWorkspaceAsHome>
            <wrapperLocation></wrapperLocation>
            <passAllAsSystemProperties>false</passAllAsSystemProperties>
            <passAllAsProjectProperties>false</passAllAsProjectProperties>
          </hudson.plugins.gradle.Gradle>
        </preBuildSteps>
        <postBuildSteps/>
        <postSuccessfulBuildSteps/>
        <postFailedBuildSteps/>
      </hudson.plugins.release.ReleaseWrapper>
    <hudson.plugins.build__timeout.BuildTimeoutWrapper plugin="build-timeout@1.14.1">
      <strategy class="hudson.plugins.build_timeout.impl.AbsoluteTimeOutStrategy">
        <timeoutMinutes>60</timeoutMinutes>
      </strategy>
      <operationList>
        <hudson.plugins.build__timeout.operations.FailOperation/>
      </operationList>
    </hudson.plugins.build__timeout.BuildTimeoutWrapper>

[ajeans]

Thanks for the example. So this job did the actual release into the preBuild step with the standard "gradle release ...", and then built the next snapshot version.

I am afraid we cannot do that for our projects, as some of our builds require more setup than just invoking gradle and tying all the necessary tasks to :build. I am looking at one that combines env variable injection, 2 shell scripts and the gradle invocation (think C/C++/Java with JNI). My goal is to only write this crazy setup once in the build portion, and leverage it for releases. If I do the complete release in the preBuild step, then I have to duplicate this setup there too...

[Hillkorn]

This means you don't let Gradle do the release right? Why don't you use beforeReleaseBuild and let it depend on tasks that do the steps? project.exec can also run shell commands for example

Arnaud Jeansen notifications@github.com schrieb am Do., 21. Dez. 2017, 16:27:

Thanks for the example. So this job did the actual release into the preBuild step with the standard "gradle release ...", and then built the next snapshot version.

I am afraid we cannot do that for our projects, as some of our builds require more setup than just invoking gradle and tying all the necessary tasks to :build. I am looking at one that combines env variable injection, 2 shell scripts and the gradle invocation (think C/C++/Java with JNI). My goal is to only write this crazy setup once in the build portion, and leveraging it effortlessly for releases. If I do the complete release in the preBuild step, then I have to duplicate this setup there too...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/researchgate/gradle-release/issues/238#issuecomment-353379020, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsepLqIESlRJRa25y_1TV-g-018fi3-ks5tCnj5gaJpZM4RCRxl .

[ajeans]

No the gradle release plugin does the release during the postStep (once the build with the release version has concluded) with the "preTagCommit createReleaseTag updateVersion commitNewVersion" tasks. Or did I misunderstand your question?

Regarding beforeReleaseBuild, I am fuzzy on what it does but I thought it triggered the tasks that are scheduled before the build... So I tried using "gradle beforeReleaseBuild" on its own in the before step rather than "gradle createScmAdapter initScmAdapter checkCommitNeeded checkUpdateNeeded unSnapshotVersion confirmReleaseVersion checkSnapshotDependencies" but it didn't trigger anything and that confused me.

Thanks for your time on this.

[Hillkorn]

That step is made for custom preparation. Same as the afterReleaseBuil that we use to upload the artifacts

Arnaud Jeansen notifications@github.com schrieb am Do., 21. Dez. 2017, 17:04:

No the gradle release plugin does the release during the postStep (once the build with the release version has concluded) with the "preTagCommit createReleaseTag updateVersion commitNewVersion" tasks. Or did I misunderstand your question?

Regarding beforeReleaseBuild, I am fuzzy on what it does but I thought it triggered the tasks that are scheduled before the build... So I tried using "gradle beforeReleaseBuild" on its own in the before step rather than "gradle createScmAdapter initScmAdapter checkCommitNeeded checkUpdateNeeded unSnapshotVersion confirmReleaseVersion checkSnapshotDependencies" but it didn't trigger anything and that confused me.

Thanks for your time on this.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/researchgate/gradle-release/issues/238#issuecomment-353388716, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsepKkf0PLvUop0gy8nX_19269BwZEIks5tCoGVgaJpZM4RCRxl .

[ajeans]

OK. So what do you think? Should I take the time to add a knob to force the commit? Or do you see a better way to achieve what I need?

Thanks.

[Hillkorn]

Not sure. I don't know if it is really necessary as I don't understand the process of your releases completely

Arnaud Jeansen notifications@github.com schrieb am Fr., 22. Dez. 2017, 12:53:

OK. So what do you think? Should I take the time to add a knob to force the commit? Or do you see a better way to achieve what I need?

Thanks.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/researchgate/gradle-release/issues/238#issuecomment-353583942, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsepNoKS4cP9lJ0ThK1WwTvINbNngufks5tC5hVgaJpZM4RCRxl .

[ajeans]

Happy holidays everyone. So how can I help explain my process? Would a simple project on github and the configuration of a Jenkins job help? Thanks

[Hillkorn]

Happy new year Yes some example project would be good :+1:

[GuilhermeViterboGalvao]

Happy new year (2)

[alvinlee001]

any updates on this? i need to trigger a release before publishing to nexus, but jenkins just allow release during post build, i need to do it during the build process, but there is non of this option