Deploy Versions from nexus repository

Answered

Hi,

I'm new to teamcity and I am able to build a maven project and deploy it to the server (two build configurations, one to build and one to deploy).

During the build the artifacts are uploaded to a nexus repository.

I'd like to have a prompt parameter where I can choose the versions present on the nexus and deploy the selected version.

As of today, what is the best/simple way to achieve that?



Thank you,

supermario18b

 

 

3 comments
Comment actions Permalink

Hi supermario18b,

 

Normally the approach in TeamCity is slightly different. By default, exactly what you ask for is not possible, but there are different ways to achieve it. They start by creating a build configuration, let's call "deploy", that has a snapshot and artifact dependency on the one that publishes the artifact to nexus.

-If the build that uploads to nexus also publishes the package as an artifact, then you can simply access the build results of the artifact you want to deploy, and under actions select "Promote", then run "deploy". This will immediately start the build using the one you promoted as the source. This will *not* use the package from nexus, but from teamcity itself. In theory it should be the same, but since it was your condition I thought it better to point it out.

-If you would not want to publish them as artifacts (as that will take extra space on the server), you could probably have the name of the artifact published as a parameter of the build, maybe via a service message: https://www.jetbrains.com/help/teamcity/service-messages.html#Adding+or+Changing+a+Build+Parameter . Then by using the same approach as above (minus the artifact dependency), you would be able to use this parameter to retrieve the artifact from nexus and then deploy it (or deploy directly if the option is possible). Again, the big difference here is that it does not pull the information directly from nexus, but uses teamcity history instead, even if it does take the artifact from nexus this time.

-By the use of a third party plugin, it might be possible to achieve exactly what you described. This plugin https://plugins.jetbrains.com/plugin/9076-web-parameters allows you to populate fields based on rest requests. This could in theory let you generate a workflow just as you described, but since it's a third party plugin, we cannot really provide much guidance on its usage, nor can talk about any limitations it might have, because we aren't as familiar with it.

 

Would any of this work for you?

0
Comment actions Permalink

Hi Denis,

They start by creating a build configuration, let's call "deploy", that has a snapshot and artifact dependency on the one that publishes the artifact to nexus.

I already have this kind of configuration. As you suggested I tried the "Promote" solution and it works.

 

Now the thing is how to efficiently search the build with the desired version to deploy.

I enabled the "buildLog" option to search the artifact name in the Logs of the build. But when it comes to the dots it doesn't work as I expect.

Let's say I have an artifact with the name "artifact-2.2.0.jar".

If I search "buildLog:artifact-2." it finds the build.

If I search "buildLog:artifact-2.2" it doesn't find anything.

Could you please point me to the right direction?


By the way I've also seen that there is the possibility to use the "include changes" option when running a build. That could be also a solution to have the desidered version of the artifact.

Thank you,

supermario18b

 

 

 

0
Comment actions Permalink

Does the version not match the build number (or some part of it)? The most common scenario here is that artifacts are named similarly to the build number, which makes the search much easier because you just look for the build number, which is also displayed on the build overview, which means it's commonly a visual search rather than using the search feature.

 

I'm afraid it's not possible to use search explicitly for artifacts. We have a feature request for it here: https://youtrack.jetbrains.com/issue/TW-38861, but it didn't gain much traction and was never implemented. Please feel free to vote for it if you think it's the best approach for your scenario.

 

 

0

Please sign in to leave a comment.