shillner / unleash-maven-plugin Goto Github PK

The SCM providers are currently initialized without a logger.
Add a logger bridging Maven and Java logging!

the standard logging output must be extended (tag information and SCM paths)

Create integration test setup and implement tests to ensure different scenarios.

In case of multi-module projects each module might have it's own version. These versions must be incremented independently (also using user prompts)

Plugin executions that are configured for the phases install and deploy are not executed since these phases are not called during the release.

Possible solutions:

• parse config and execute plugins standalone (difficult, error-prone, ...)
• add note to documentation that those plugins are not executed and must be run previously or as additional steps configured as workflow hooks
• nexus staging can also be implemented as a hook or maybe in the plugin itself but disabled by default.

Update of versions (release and snapshot) does not work correctly!

http://.../trunk
scm:svn:svn://.../tags/2.4.1

This could only be related to the url tag but needs to be fixed soon!

There seems to be a bug on Linux:
Passing boolean parameters as -D... (e.g. -Dunleash.commitBeforeTagging=true) seems to have no effect on Linux machines but is fully functional on Windows.

If nothing works use String parameters and parse values before producing them for later usage (String parameters work as expected)

In case of multi-module projects wrong parent POMs are deployed. This is caused by ambigous relative paths.

i'm just trying to perform a basic release against a github repository and i get the following error:

[ERROR] Error calling rollback method of Mojo.
java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:497)
    at com.itemis.maven.plugins.cdi.internal.util.workflow.WorkflowExecutor.rollback(WorkflowExecutor.java:227)
    at com.itemis.maven.plugins.cdi.internal.util.workflow.WorkflowExecutor.rollback(WorkflowExecutor.java:206)
    at com.itemis.maven.plugins.cdi.internal.util.workflow.WorkflowExecutor.executeSequentialWorkflowStep(WorkflowExecutor.java:133)
    at com.itemis.maven.plugins.cdi.internal.util.workflow.WorkflowExecutor.execute(WorkflowExecutor.java:114)
    at com.itemis.maven.plugins.cdi.AbstractCDIMojo.execute(AbstractCDIMojo.java:196)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:497)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: com.itemis.maven.plugins.unleash.scm.ScmException: An error occurred while querying the remote git repository for tag '0.2.0'.
    at com.itemis.maven.plugins.unleash.scm.providers.ScmProviderGit.hasTag(ScmProviderGit.java:613)
    at com.itemis.maven.plugins.unleash.steps.actions.TagScm.rollback(TagScm.java:166)
    ... 31 more
Caused by: org.eclipse.jgit.api.errors.TransportException: [email protected]:condevops/hello-world-jenkins.git: USERAUTH fail
    at org.eclipse.jgit.api.LsRemoteCommand.execute(LsRemoteCommand.java:220)
    at org.eclipse.jgit.api.LsRemoteCommand.call(LsRemoteCommand.java:159)
    at com.itemis.maven.plugins.unleash.scm.providers.ScmProviderGit.hasTag(ScmProviderGit.java:607)
    ... 32 more
Caused by: org.eclipse.jgit.errors.TransportException: [email protected]:condevops/hello-world-jenkins.git: USERAUTH fail
    at org.eclipse.jgit.transport.JschConfigSessionFactory.getSession(JschConfigSessionFactory.java:159)
    at org.eclipse.jgit.transport.SshTransport.getSession(SshTransport.java:136)
    at org.eclipse.jgit.transport.TransportGitSsh$SshFetchConnection.<init>(TransportGitSsh.java:264)
    at org.eclipse.jgit.transport.TransportGitSsh.openFetch(TransportGitSsh.java:162)
    at org.eclipse.jgit.api.LsRemoteCommand.execute(LsRemoteCommand.java:198)
    ... 34 more
Caused by: com.jcraft.jsch.JSchException: USERAUTH fail
    at com.jcraft.jsch.UserAuthPublicKey.start(UserAuthPublicKey.java:119)
    at com.jcraft.jsch.Session.connect(Session.java:463)
    at org.eclipse.jgit.transport.JschConfigSessionFactory.getSession(JschConfigSessionFactory.java:116)
    ... 38 more

is there some configuration setting i am missing?

update error message and provide docs for the implementations that indicate compatible plugin versions.

Provide a further goal to only update the versions to release versions! Should simply be re-orchestration of existing steps!

API extensions for more common usages in other projects:

• checkout (including empty directories -d for SVN update later on file level only)
• branching
• querying for branches

Add some questions for release and next dev versions if the build is run in interactive mode and the necessary information is missing. provide valid fallbacks!

There are potentially a number of scm changes that have to be reverted in case of a failure!
Take remote changes into account (updates might have been done during work and an update might be necessary during rollback!)

For the execution of HTTP requests

Maybe add support for extended release information such as:

• release notes
• SCM History (commits since last release)
• Dependency analysis (changed dependency versions, ...)

Ancestor could be latest release which can be calculated automatically.

In case that the commit of the development version failed the rollback of step SetNextDevVersion fails with an exception like this:

[INFO] 23:09:06,517  Preparing project modules for next development cycle.
[INFO] 23:09:12,567  SVN - Committing to remote repository.
[INFO] 23:09:23,271  Rollback of all pom changes necessary for setting of the development version as well as reverting any made SCM commits.
[ERROR] Error calling rollback method of Mojo.
java.lang.reflect.InvocationTargetException
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:497)
        at com.itemis.maven.plugins.cdi.internal.util.workflow.WorkflowExecutor.rollback(WorkflowExecutor.java:227)
        at com.itemis.maven.plugins.cdi.internal.util.workflow.WorkflowExecutor.rollback(WorkflowExecutor.java:206)
        at com.itemis.maven.plugins.cdi.internal.util.workflow.WorkflowExecutor.executeSequentialWorkflowStep(WorkflowExecutor.java:133)
        at com.itemis.maven.plugins.cdi.internal.util.workflow.WorkflowExecutor.execute(WorkflowExecutor.java:114)
        at com.itemis.maven.plugins.cdi.AbstractCDIMojo.execute(AbstractCDIMojo.java:208)
        at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
        at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
        at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)
        at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)
        at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:497)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
        at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
        at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: java.lang.IllegalStateException: No from revision set (start revision of the reversion)!
        at com.google.common.base.Preconditions.checkState(Preconditions.java:174)
        at com.itemis.maven.plugins.unleash.scm.requests.RevertCommitsRequest$Builder.build(RevertCommitsRequest.java:187)
        at com.itemis.maven.plugins.unleash.steps.actions.SetNextDevVersion.rollback(SetNextDevVersion.java:132)
        ... 31 more

Do we need a dry-run feature?
Maybe this could also be a feature of the base mojo (dry-run execution of the steps)

For execution of single commands

Hi,

Kudos on the great work you are doing, and the awesome docs! Can I know whether it is possible to run the unleash:perform without adding the plugin configuration into the pom.xml?

I'm trying to push for a automated release via Jenkins. But, first I need to show how it works. So, I'd appreciate if this is possible. Only issue could be the need to specify the scm provider as a dependency to the unleash plugin. I'm a bit confused about the step 3 of Usage.

I'm testing it out right now. But thought to reach out and let you know that I'm trying to use your project, and get your feedback as well if possible.

There is the class PluginParameterExpressionEvaluator which could be used to evaluate all parameters as Maven does.

Currently there is a check that ensures that at least one module is releasable which means that at least one module must have a SNAPSHOT version.

The intended behavior should be that a multi-module project can be released under the following conditions:

• all modules have SNAPSHOT versions OR
• at least one of the modules has a SNAPSHOT version AND
  • Maven is in batch mode and flag says "release SNAPSHOTS" (releases only the snapshot modules)
  • Maven is in batch mode and user says "release ALL" (releases all modules -> already released ones with the next higher release version)
  • Maven is in interactive mode and user says "release SNAPSHOTS" (releases only the snapshot modules)
  • Maven is in interactive mode and user says "release ALL" (releases all modules -> already released ones with the next higher release version)

If none of the above conditions match the release process should fail with an appropriate error message and a hint to the flag that can be set.

In case of an error the output is sometimes not sufficient.
F.i. if the SCM provider doesn't match the API version the error output does not point to that and does not suggest potential steps to resolve this error.

The dependency check fails if a module of a multi-module project references another module of the same project using the version property ${project.version}. Those dependencies should be filtered out during the checks since these properties will be replaced by the release version later.

This failure is caused by a wrong comparison which includes the type of the dependency. Issue #35 handled a similar case where the classifier was the cause.

Adding the spy-plugin implies a POM modification (addition of the plugin to the plugins section of the build)
In a special case this modification is erroneous which causes the build to run without the spy plugin. The result is that the spy output is missing and the release will rollback.

Setup which causes the issue:

• POM with a profile that contains a build section (profile is not activated during standard build)
• The POM itself does not contain a build section

<project>
  ... <!-- no build section here -->
  <profiles>
    <profile>
      <id>...</id>
      <build>
        <!-- plugin will be added in the plugins section of this profile -->
      </build>
    </profile>
  </profiles>
</project>

The point is that the plugin must be added to the standard build section which must be created on demand.

As discussed in #37 Nexus staging support could be part of the plugin or an external hook.

releases are failing in jenkins and i believe the cause is related to jenkins checking things out in a detached state. i currently set the option to check out to a specific local branch (this is also required by the maven-release-plugin to work properly) but the plugin does not seem to notice this.

from the logs:

[DEBUG] 14:00:01,078 Git - Push info:
- WORKING_DIR: /var/lib/jenkins/jobs/hello-world-jenkins/workspace
- LOCAL_BRANCH: master
- REMOTE_BRANCH: null
- REMOTE: origin
- REMOTE_URL: [email protected]:condevops/hello-world-jenkins.git
- MERGE_STRATEGY: FULL_MERGE

this can be reproduced locally be executing the same steps jenkins does on a check out.

i am currently digging into this and will hopefully have a fix soon but there will be no complaints from me if you beat me to it.

The dependency check fails if a module of a multi-module project references another module of the same project using the version property ${project.version}. Those dependencies should be filtered out during the checks since these properties will be replaced by the release version later.

Investigate the Maven version requirements (currently 3.2.1).
Is it possible to downgrade the required version?

Currently there is only the possibility to specify default versions for release and dev globally for the whole project. But the intention is to specify those versions per module instead.

multiple commits are produced for multi-module projects (setting next dev-version)

Maven invoker can be outsourced to a special utility class instead of using directly in the steps.

implement Git SCM provider (own repo)

Implement eclipse tycho build features:

• version setting using the tycho-versions-plugin
• copying of the update site, ... (currently problematic because the version string @{project.version} resolves to the snapshot version instead of the release version)

We need a check of the SCM state at the beginning of the process (SCM must be up to date).

• SVNs local revision is behind after commits, ... so we could update if this is the case.
• Can we also start with an outdated working copy if no commit is requested before tagging? update is done before setting the next snapshot version

Extend the SCM Provider API with history features:

• history of local working copy
• remote history
• restrict number of results
• specify commit range (revisions)
• specify tag range (record changes between two tags)

Hi,

We are evaluating a couple of Jenkins plugins to automate the release process. Can you let me know whether this plugin support Sonatype Nexus as in M2 Release Plugin?

remove data provider stuff and use junit theories, ...

Maybe use the metadata to add reporting functionality (add serialization feature)

We need some hooks (additional processing steps) for custom tasks during the release build. These might be groovy, shell/batch scripts, HTTP calls (REST) or simply a command execution.

Add an option to set the name of environment variables for SCM username and password. Also investigate on certificates and system keystores, ...

Sometimes the rollback of POM changes destroys the POM files and produces emtpy POMs that only contain the XML header.

Implement offline check and fail if workflow contains online steps (checkAether, deploy, tag, ...)
Maybe implement this step in the cdi-utils and provide online-requirement per step. Could automatically check and fail in case of offline builds.

Create a new Repository for the Plugin!

If used with a private maven repository as it is possible on Jenkins or other CI servers, the tags include the private repo when tagging from working copy instad of tagging from repository.
Sure this only happens if the repo is created within the project workspace.

Maybe add some excludes to the tag creation or exclude resources starting with a dot by default.

There could be an issue with the Maven invoker as it is used currently.
We do not set the settings files, ... and these paths are also not inherited from the current instance.
Are there more properties to set?

It is hard to get the paths from the running instance and a possible solution could be to let the user pass the path to the settings files again as a plugin parameter. Not nice but could be necessary.

Implement API version check to avoid non-matching API-Impl versions

For the execution of scripts

The release arguments (system properties) are not passed to the actual release build. The implementation uses a wrong method and sets the maven opts instead.

Extend the SCM provider API with a method for diff creation

• the request should contain settings which determine the diff type (text comparison, changed files only)
• either return the diff as resulting text or diff items or let the providers serialize the diff
• depth
• filters (files, commits and messages)