we have a problem with maven releases and maven version plugin. In Jenkins we want to do releases automatically upon pressing a button. To remove snapshot dependencies we want to use the maven versions plugin. Suppose we have two projects A (latest release 0.0.1, latest snapshot 0.0.2-SNAPSHOT) and project B with a dependency on ProjectA - 0.0.2-SNAPSHOT and we want to release project B. How can we upgrade project Bs dependencies to the latest available release version? The maven versions plugin goal "use-releases" does not change the 0.0.2-SNAPSHOT dependency because there is no 0.0.2 release version of this project.
So my question is: how can we automatically remove snapshot dependencies and replace them with the latest available release version in our scenario?
Using maven-release-plugin should be enough. There are two steps release:prepare and release:perform. When you do release:prepare settings those args developmentVersion and releaseVersion what would do the plugin is remove the SNAPSHOT for the current release (use releaseVersion) and then prepare for your next development iteration (use developmentVersion) and other things like commit in your SCM and tag the code.
For more information you can take a look maven-release-plugin docs.
Related
In Jenkins, currently there is only JDK8 and maven 3.5.2 installed. I downloaded JDK11 to it. I ran a pipeline project to build a springboot Java11 project and it ran fine using maven 3.5.2. There is no reference to any maven source or target versions in the pom of the project. Currently I don't see any issues with JDK11 with maven 3.5.2 due to simplicity of the project. Any idea if it might cause issues with complex projects? Is it good to update Maven version in Jenkins and the spring boot projects?
What determines the version(s) of the build steps for ".net core" available in TFS2017 on prem?
I've patched tfs up to date, installed .net core version 2.2 on build and tfs servers, but I can only see v0.* and v1.* in the TFS build steps.
Edit to clarify: it's the version of the build step template I'm interested in, not sdk/framework/dotnet exe on the servers.
Tasks are versioned, each task in a pipeline has a Version selector to let you choose the version you want. And you must specify the major version of the task used in your pipeline. This can help to prevent issues when new versions of a task are released.
Tasks are typically backwards compatible, but in some scenarios you may encounter unpredictable errors when a task is automatically
updated.
When a new minor version is released (for example, 1.2 to 1.3), your
build or release will automatically use the new version. However, if a
new major version is released (for example 2.0), your build or release
will continue to use the major version you specified until you edit
the pipeline and manually change to the new major version. The build
or release log will include an alert that a new major version is
available.
More details you could refer to this official link-- Task versions
What determines the dotnet (core) build step versions available on perm Usually it's related with your TFS version. New version TFS include new version task by default. That make sense, since for some old TFS when it's released, the new version task is not release or in development.
For example with my Azure DevOps 2019 update1, you will be able to select version 2(latest) of this .NET Core CLI task.
If you really need the latest version, you could also consider package the task DotNetCoreCLIV2 and upload it by yourself. But we could not guarantee compatibility on old version TFS, some scenarios you may encounter unpredictable errors.
When I create a new Gradle project, the Gradle version is 3.3. But when I import an existing Gradle project, the Gradle version is 2.4.11. How are the version determined, especially the last one, because as far as I can see, there is no Gradle version information in the existing Gradle project.
I don't know am I understand your issue correctly or not. But as I understood:
The version of gradle is determined in your build.gradle file.
There is a line there like below:
classpath 'com.android.tools.build:gradle: 2.2.2'
which 2.2.2 is the version.
the highest stable version till now is 2.2.3 (which it is not suitable for me) .
Note that versions above 2.2 need jdk 8 (not work with jdk 7)
I found out that you have to look at the file gradle/wrapper/gradle-wrapper.properties. The last line of this file gives the Gradle version:
distributionUrl=https\://services.gradle.org/distributions/gradle-3.3-bin.zip
Before importing an existing Gradle project, maybe you want to edit this line.
I am using Maven to automate build process of Install4j.
For every release product, POM version is updated. I want when pom version is updated Install4j version should be updated (under General Setting-> ApplicationInfo->Version).
How can i automate version in install4j file. So that version should always remain latest for my product installer.
You can set the release parameter for the install4j compile target to set the version from the maven plugin. See
http://sonatype.github.io/install4j-support/install4j-maven-plugin/compile-mojo.html
for more information.
I want to change build number each release and it should start with build number 1 such as
1.0.1, 1.0.2 and so on - Release
2.0.1, 2.0.2 and so on - Release
I'm using following two plug-ins to have build version as 1.0.1
Build Name Setter Plugin: https://wiki.jenkins-ci.org/display/JENKINS/Build+Name+Setter+Plugin
Next Build Number Plugin: https://wiki.jenkins-ci.org/display/JENKINS/Next+Build+Number+Plugin
Currently, I need to cleanup old build before changing the version from 1.0.100 to 2.0.1 and I loose build histories and no longer available on jenkins dashboard.
All available plug-ins just set the build display name not the actual build version.
Is there any plug-in which can keep track of major minor version and also maintain the build history?