[HOWTO] Maven Release on JetBrains TeamCity

In one of my last posts I wrote about setting up a C# build job on JetBrains TeamCity 9. Today I’ll show you how to set up a java build job for building and releasing a maven artifact. The activiti wrapper will be used as an example project. It’s a maven project that will be released by using the Maven Release plugin.

Before creating build configuraitons for java projects, the following conditions must be met on the host system:

HINT: The TeamCity instance used here has no external build agents configured and runs under system account.

Setup

Go to your TeamCity server and perform the follwing steps

  • Create a new project from URL
    • Enter the repository URL, the username and the password as demanded
  • Navigate to the settings of the newly crated project
  • Under VCS Roots you can edit the existing VCS root to define the branch to check out (in our case this would be the release branch)
    TC-mvn-release-vcs-1

    TC-mvn-release-vcs-2

  • Upload the maven settings.xml file which should be used for the release to the TeamCity server
    TC-mvn-release-mvn-settings
  • Go to General Settings, choose the auto detected build configuration and click on edit (NOTE: In this sample there are two configurations because one of them was added manually in advance)
    TC-mvn-release-general
  • Navigate to the Version Control Settings and change the VCS checkout mode to Automatically on Agent
    TC-mvn-release-vcs-chekcout-options
  • Go to the Build Steps menu, delete the existing build step and create two new build steps
    • Build step for release:prepare
      TC-mvn-release-prepare-step
    • Build step for release:perform
      TC-mvn-release-perform-step
  • Last but not least the parameters referenced in the build configuration (release:prepare) have to be defined

    • Go to Parameters menu and define the following parameters to be prompted
    • env.development.version
    • env.git.password
    • env.git.username
    • env.release.version
      TC-mvn-release-parameters

    The parameters were specified as follows
    TC-mvn-release-parameters-popup

Troubleshooting

Maven release:prepare hangs

Almost always the release:prepare goal of the maven release plugin hangs, the problem is that the GIT password is not set. In such a case the actual build has to be stopped and the password has to be set (i.e. according the manual above)

JRE instead of JDK

If the error message No compiler is provided in this environment. Perhaps you are running on a JRE rather than a JDK? occurs while the maven release plugin is preparing the release you have to install a java JDK on the build agents host system.

[ERROR] COMPILATION ERROR : 
[INFO] -------------------------------------------------------------
[ERROR] No compiler is provided in this environment. Perhaps you are running on a JRE rather than a JDK?
[INFO] 1 error
[INFO] -------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------

Please tell me who you are

If the error message Please tell me who you are occurs on maven release:prepare the following commands have to be run on the build agents host system:

git config --system user.name "John Doe"
git config --system user.email john.doe@example.com

icon_TeamCity
The TeamCity Free Open Source License was generously provided by JetBrains

Comments

  1. Vasilii Ruzov says:

    Hi Marc. Thank you for tutorial, but I have some questions regarding password storing. I followed your steps and did the same. After that I see that if I use simple git scm provider then in case of typo in password git prints my mistyped password to log. Even if there is a mistake it is still a critical security issue. Then I changed my scm provider to jgit and this solved the problem described. But I faced the 2nd problem. If you click on ‘view thread dump’ during build then you can find the whole command line for this build including password in __plain text__. It does not depend on scm provider and it’s just a teamcity bug which is not fixed in latest version. And 3rd problem I see: during and after the build there are /target/.git/config file which contains your username and password in plaintext. And this problem cannot be solved easily too.
    Do you know how to workaround these issues?

    sorry. typo in email. right one: ruzov.vo@gmail.com

    • Hi Vasili. Thank you for making me aware of these issues. I tried to reproduce the problems with one of our Java build jobs. Unfortunately I was not able to view the thread dump and there was no config file in /target/.git/. I don’t know if this file only gets generated if you’re using jgit. Concerning passwords in general I prefer using SSH keys over passwords for git as described in [another blog post](https://d-fens.ch/2015/09/02/nobrainer-use-ssh-key-on-jetbrains-teamcity/) . I would recommend trying to use a SSH key and then check if you are still facing the issues mentioned in your comment. Please let me know if using SSH keys resolved the problems.

      • Vasilii Ruzov says:

        Thank you for quick response. The link you’ve provide describes how to set ssh key for vcs root. But do you still need to set username and password on release:prepare step? If yes, this won’t resolve my problem. My use-case is to let run the build only to people who have write permission to my repository. As release:prepare makes commit/push with version change and tag build will be terminated if person who triggered the build has insuffitient permissions.
        So I want my users to type their username/password or another credentials(maybe ssh-key or smth other) to run the build. Do you know how to do it?

      • Hi Vasili. You’re right. I checked my build plan and I still have to provide a username and a password to run maven release:prepare. For that case I created environment variables under Parameters of the release configuration as follows:

        Name:
        env.git.password

        Spec:
        password description=’GitHub password used for maven release’ label=’GitHub Password’ display=’prompt’

        Name:
        env.git.username

        Spec:
        text description=’GitHub user name used for maven release’ validationMode=’any’ label=’GitHub user name’ display=’prompt’

        In the release:prepare step of the build configuration I defined the following “Additional Maven command line parameters”:

        -Dtag=activity.wrapper-%env.release.version%
        -DreleaseVersion=%env.release.version%
        -DdevelopmentVersion=%env.development.version%
        -SNAPSHOT -Dusername=%env.git.username%
        -Dpassword=%env.git.password%

        That allows you to enter username and password for every release. Additionally the user that starts the release build can define the release and the development version (Defined environment variables too). I don’t know, if the username and the password get logged in this case. I hope I could give you some further hints how this could probably work.

      • Vasilii Ruzov says:

        Hi Marc. I understand about -Dusername and -Dpassword. And this is actually what causes problem. These parameters are visible in plain text in process explorer(in command name on build agent. in unix I use `ps -ef` to see processes and commands), thread dump of running build(don’t know why you don’t see it because I can reproduce it without any problem. you just need to wait untill prepare step is being run and then expand current or parent process command line. all on teamcity web-ui). So I’m looking for some anoter _secure_ way to authorize the user who triggered the build in git to write version change commits on behalf of him or terminate the build in case of insuffitient permission.

      • Hi Vasilii. Ok, I see. So if setting these paremeters in maven release:prepare step they still get logged out. Sorry for the circumstances and that I couldn’t help you out. I don’t know how to avoid logging the credentials. As you already said this could be a bug in TeamCity. It would be glad if you could add a comment how you solved the problem as soon as you found a solution!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: