I'm probably approaching the problem all wrong, but here goes...
We want to implement a development -> releases/x.y.z -> master workflow using Gitlab and Nexus. The artifacts should be labelled x.y.z-SNAPSHOT, x.y.z-rc and x.y.z respectively.
In the ci-build.yml, I have tried to modify the POM depending on the current branch so as to create the correctly labelled artifacts. The problem is obviously that the change will be one commit ahead of the current build commit and the POM used in the build has the original version.
e.g.
a release branch is created from development
the POM has 2.3.4-SNAPSHOT and, during the ci-build, is modified to 2.3.4-rc and is committed and pushed to git
the subsequent build and deploy actions are executed but this deploys a 2.3.4-SNAPSHOT package to Nexus and not 2.3.4-rc as wanted
My question here is the following:
Can I modify the POM and use the updated POM in all following stages of the ci-build?
(I don't feel that this is the correct procedure, but it is what my team-leader has requested so I'm trying to implement it...)
My solution was to avoid commits altogether and use the strategy described in https://maven.apache.org/maven-ci-friendly.html.
This defines a new property, revision, which can be set using a maven parameter, -Drevision=x.y.z-SUFFIX. The POM version is set from this variable.
The build-ci reads project/properties/revision to extract the POM version and alters the version as appropriate depending on the current branch.
Using this approach I can achieve the required results without adding any extra commits as Maven can execute its goals using the version provided externally.
Related
I am using maven-versions-plugin in my pom and utilizing its "update-parent" goal and "commit" goal.
What it does during the regular build (auto-build or auto-scan which happens every week) is to lookout for any latest version available in the artifactory for the parent pom it refers to, but it does not commit the changes to the remote.
In the build logs, I can see that it tries to lookup the latest version updates it and even shows accepting changes to pom.xml
Wanted to seek help from community to understand what next steps (plugins, extensions) I should use in order to persist this update to the parent pom version in the pom file, to the remote repository as well?
So I'm working for a customer that uses mvn deploy statements in his build scripts and I'm trying to figure out a way to prevent maven to accidentally overwrite artifacts in the release repo of Artifactory, for instance if a developer forgets to mark his POM version with -SNAPSHOT on his feature branch.
I'm no maven expert, but I've seen some suggestions, like using certain maven plugins, but these plugins' usage must be configured in the POM and then I'm back where I started, what if this is forgotten on a feature branch? There must be an established method to ensure that no artifacts from feature branches are deployed into the release repo and that no artifacts from release branches are deployed into the snapshot repo by accident.
One way I can think of and that also has been suggested is, to simply disallow redeployment on the release repo in Artifactory, but what if I have a validation build that fires after a PR is created and then another CI build fires and tries to redeploy?
Is there another good way to achieve this?
One solution is to ensure specific users/groups do not have the Delete permission.
See more here: https://www.jfrog.com/confluence/display/JFROG/Permissions#Permissions-RepositoryPermissions.
NOTE: I haven't used Artifactory in a while, but this makes sense according to the docs.
I've been asked to do this, so please don't suggest that I shouldn't need to. :-p
We currently build a multi-module project with Maven. We have no problems doing so. We're using the Maven release plugin, and we get SNAPSHOT builds for development and release builds in Jenkins. The release plugin automagically increments the 3rd place of the version string. Life is good.
But, I've been asked to add a 4th place in our version strings, which is populated with the Jenkins build #.
The canonical way I see suggested to do this works fine with a single module: You define a property like build.number, to have a default value of "0-SNAPSHOT", and you define your POM to have a element value like "1.9.${build.number}". And, you set your Jenkins job to define build.number to be the Jenkins build #, for its invocation of Maven.
That would be great, if we had a single module, but we don't. We have multiple modules, and in Maven I can't either
1. not specify a version in the child module POMs, nor
2. use a property in the version of the child module POMs.
I gather it's a bad idea for Maven POMs to try to produce multiple artifacts in a single module (using. say, profiles), so I don't want to try to smoosh this project down to a single module.
I probably could try instead splitting it into separate projects, except that seems drastic, and besides, this project really is producing very tightly-related artifacts, so I want to be sure to build all the artifacts for any source code change in the project.
Any solutions?
The maven-release-plugin has two parameters named releaseVersion and developmentVersion. There you set the version to build and the next version, respectively.
Using Jenkins, you can fill these variables with Jenkins generated content, using e.g. the build number. If you want to read the parts of the version number from the POM, you can use build-helper:parse-version and use terms like ${parsedVersion.majorVersion}.
Is there a way to determine that a new SNAPSHOT version of a dependency is available in a Nexus? Ideally it would be a command line that would take as input a group/artifact/version and would return true if it is the case.
Say I have mygroup.b1:1.0.0-SNAPSHOT which has as dependency mygroup.a1:1.0.0-SNAPSHOT, both version controlled and managed by my continuous deployment environment.
I would like for a build of mygroup.b1:1.0.0-SNAPSHOT to be triggered when a new SNAPSHOT of mygroup.a1 has been deployed in Nexus.
In my case, the continuous environment is GOCD Thoughtworks and I would like to trigger a pipeline based on the dependencies defined in a pom.xml file (that of mygroup.b1), some of which are SNAPSHOTs (such as mygroup.a1) that other pipelines could deploy.
I have looked at https://github.com/jenkinsci/maven-dependency-update-trigger-plugin which seems to do this by checking a dependency is downloaded when it is resolved. Since this is a Jenkins plugin it is not exactly what I am looking for.
I have also looked at https://github.com/aresok/go-maven-poller but the process seems tedious: is it required to define all dependent packages so that GOCD can poll Nexus?
Another thing is the usage of the versions:display-dependency-updates goal of the versions-maven-plugin http://www.mojohaus.org/versions-maven-plugin/display-dependency-updates-mojo.html but it does not seem to allow filtering on gav.
EDIT: added an example
EDIT: added information on the usage of the maven-versions-plugin
We currently have multiple feature releases in perforce. Each of these branches has POM files that contain a version tag and name tag that is tied to that branch.
When we run sonar:sonar each branch scan overwrites another branch scan and you only see one at a time in the sonar gui.
Can a sonar project be tied to maven GroupId>ArtifactId>Version or even instead of just being Tied to the GroupId.
FYI, GroupId and ArtifactId do not change when we branch the POM.
I found your question while searching for a similar topic, and I noticed you had not received an answer. If you pass the -Dsonar.branch, each branch will be treated as a different project. As documented here:
http://sonarqube.15.x6.nabble.com/Sonar-Analysis-for-Feature-Branches-td5004642.html#a5004647
Hope this helps.