I need some help about the maven release plugin !
FIRST
I encountered an issue that is obstructing my development on Jenkins.
After installing the maven-release-plugin on Jenkins I've tested it.
The fact is that for a project without any dependencies, the plugin works
well.
But since I have some project dependencies it doesn't. Indeed after
selecting the "Default versioning mode" as "Specify version(s)" ,when I
save he configuration and try to perform maven release build, the "Default
versioning mode" parameter keeps its state, whatever I change it to and
simply goes back to ''none'' state. There is no way to modify it !!!
My main goal here is to specify my release version of a dependency and
this is what the "Default versioning mode" is done for because
maven-release-plugin can't work with SNAPSHOT dependencies !!
SECONDLY
Finally to solve this problem I downgraded the maven release plugin to the 0.7.1 version and now I can select the default versioning mode :D.
But the second issue I faced is that I want to release a job which depends on other one.
Project B ---------> Project A
depends on
The fact is I released the Project A in a 0.0.X version.
Now I would like to use/implement this Project A release during the release of the Project B because I don't want any SNAPSHOT dependencies in my released projects !!
I also tried using versions-maven-plugin but the use of both those plugin seems not to work together ... Am I wrong ?
All I want to do is working while using the cmd !!
Anyone encountered this problem yet ? is there a solution to it ?
JENKINS 1.596 & maven-release-plugin 0.7.1
Related
I have updated my jenkins server and see the following message for some plugins. I am not sure how to fix this. I looked at the dependencies section for that plugin and I see they are already installed. Not sure what else is missing so I can see the update available. Dependency for this is Mailer which is already installed on my server.
That is frustrating but you can try uploading plugins manually.
You can download plugins from here link to plugin storage.
Of course you have to roughly see what version of the plugin goes with your jenkins version.
Once you downloaded 'proper' plugin version, you go to manage plugins, advanced tab and there you can upload the plugin file. After that restart jenkins and check changes. You should really go to manage plugins, updated plugin tab and update selected plugins...
It could be guess work, but I'm sure after a couple of guesses you'll get to the version of Jenkins you have.
You might need to upgrade jenkins.. here are all jenkins war files:
https://get.jenkins.io/war-stable/
Last but not least... don't try to fix all dependencies.. fix those you use, rest is optional.
I am trying to build my packages using TFS, already integrated with octopus server so that the package can be pulled to octopus server afterwards and get deployed automatically.Created a build definition to build db and windows packages. it goes successful for db however stuck in case of windows where it is supposed to create a release for its deployment.Error -:
There was a problem with your request.
- Release '20170808.12' already exists for this project. Please use a different version, or look at using a mask to auto-increment the number.
Error from Octopus server (HTTP 400 BadRequest)
Could anyone please help me on it....
Thanks in advance !!
You are attempting to a create an Octopus Deploy Release with a name which already exists.
You could adjust your version strategy through AssemblyInfo.cs or adjust Octopus Deploy to not use package names for Releases for under Octopus -> Project -> Settings
Please check if the Release '20170808.12' already exists.
According to the description in this article, it should be an Octopus Deploy issue.
Which version of Octopus Deploy do you use? If you are using the old version, just trying update to the latest version.
In addition, you can try to use below Create release options to check if that works:
--ignoreexisting If a release with the version number already
exists, ignore it
--force [Optional] If a project is configured to skip
packages with already-installed versions,
override this setting to force re-deployment
(flag, default false).
Also try to create a release with a specified release number:
octo create-release --project HelloWorld --version 1.0.3 --server http://octopus/ --apiKey API-ABCDEF123456
See creating-releases for more information.
Let's say my solution have 2 package dependencies:
3rdParty.CompanyA.ProductA version 4.0.1
and 3rdParty.CompanyB.ProductB version 2.0.1
Both packages reference other package dependency "C".
The dependency for the first one is set to "higher then 1.2 - (>1.2)" , and the other one set to "higher then 1.8 - (>1.8)".
When I'm locally compiling the solution all works fine and the "C" version in the bin directory is the newest "1.8" as expected....
But when I compile this solution in TFS and reference the same .Nuget\NuGet.config file I'm getting the old 1.2v "C" version in the bin directory and therefore my product getting broken.
Is there a special configuration to notify TFS restore to take the version that will match all dependencies?
Update
I think I know where my issue is coming from and yet I'm net quite understand it.
In TFS I'm compiling and restoring packages for 8 projects.
After the compilation is over I run UnitTest with the "Test Assemblies" step.
I found out that with the default setting my unittest get broken due it referencing old DLL. But when I turn on the "Run In Parallel" it's working as expected.
Not sure if totally got your point. In my opinion, the two packages should in the some project. If not, there will be two bin folders one for 1.2 and one for 1.8.
It's a cousin dependencies concept in Nuget Restore:
When different package versions are referred to at the same distance
in the graph from the application, NuGet uses the lowest version
that satisfies all version requirements (as with the lowest
applicable version and floating versions rules). In the image below,
for example, version 2.0 of Package B will satisfy the other >=1.0
constraint, and will thus be used:
Source: How NuGet resolves package dependencies
It's also using NuGet.exe int TFS NuGet restore task. There shouldn't be any additional settings or parameters. Suggest you to enable debug model in TFS and go through more detail logs for trouble shooting. Otherwise, just use the simply workaround change the dependency for the first one also setting to "higher then 1.8 - (>1.8)"
Update
Suggest you just turn on the "Run In Parallel" of the VS test task, tests will run in parallel leveraging available cores of the machine. For how tests are run in parallel please refer Parallel Test Execution A good choice in this situation.
AEM muti-module project has pom.xml at each module level. Version can we changed at that level, new build shows the artifacts with updated version.
With versions, there would be a new AEM Package created for each version. We would want to uninstall/delete the old package before installing new version.
Question is, how can we handle the uninstallation/deletion part of old package (new package to be installed is of different version) in CI-CD job? We could think of following solutions
Query the list of packages to get the version and use that to uninstall.
Pass version as parameter to Jenkins Job in "Build with Parameters". But automatic build trigger on code check-in could have issue.
Has anyone faced similar situation? Please share if there is best practice which is followed for AEM CI-CD jobs for handling different release versions.
Querying the list of packages is your best option I think. You can collect any previous version of your package then, no matter when you deployed that specific package to that server the last time.
An alternative option might be to delete the package immediately after installing it, but I fear there might be lots of problems waiting for you then:
Some packages need a restart, you may not delete the package to early, ...
As I said, I would go for the querying solution.
We're building a continuous integration pipeline for the project I'm working on. We have a number of build artifacts (both JAR and WAR files) which we have versioned and deployed to an Artifactory server.
All our JARs start at version 0.0.1-SNAPSHOT. As we develop, we'd like to mark milestones by setting a particular point in the codebase as 0.0.1, and starting development on 0.0.2-SNAPSHOT. Eventually, a particular version will get accepted by QA, and promoted to 0.1.0, and we will start working on 0.1.1-SNAPSHOT. The same process will happen with a release to Production, when we reach 1.0.0.
I can't seem to find a plugin for Jenkins that supports this kind of versioning. Ideally, it would track the current version of each WAR and JAR, and once it hit a particular point (after running acceptance tests) it would automatically increment the version. Does such a thing exist?
You can make use of the gradle-release plugin. Please find different approaches that are documented here