I am setting up Jenkins 1.452 with the Promote Build plugin to promote builds. I have a very simple 2 step Promotion path right now.
Compile and Install (creates Jar)
UAT Deploy (Pushes Jar to my application server)
I have this broken into 2 jobs, and both run successfully on their own - however when I try to setup the promotion process I the following error:
Legacy code started this job. No cause information is available
Building in workspace /Users/theatre/.jenkins/jobs/ActiveCQ API (Compile)/workspace
Promoting ActiveCQ API (Compile) #38
scheduling build for ActiveCQ API (UAT Deploy)
Recording fingerprints
ERROR: Build artifacts are supposed to be fingerprinted, but build artifact archiving is not configured[8mha:AAAAWB+LCAAAAAAAAABb85aBtbiIQSmjNKU4P08vOT+vOD8nVc8DzHWtSE4tKMnMz/PLL0ldFVf2c+b/lb5MDAwVRQxSaBqcITRIIQMEMIIUFgAAckCEiWAAAAA=[0mbuild hudson.tasks.Fingerprinter#217aa061 FAILURE
Archiving artifacts
build hudson.tasks.ArtifactArchiver#79b75172 FAILURE
Finished: FAILURE
I am attached screen caps of the config for the (Compile) job.
I have Fingerprinting and Archiving setup, and I can even see the list of artifacts w their fingerprints listed in the console.
Compile build screenshot
UAT Build Showing Archived Artifact w fingerprint
UAT Build Job Config
Some recommendations I would suggest:
Do NOT archive and fingerprint in a promotion process. A promotion process is really a separate job and a separate build. Instead, you should archive and fingerprint the files in the Compile job's Post-build Actions. The compile job has to be the origin of the fingerprint for the promotion process to work robustly.
In the Deploy job, somehow get the same file that was fingerprinted in the Compile job and also fingerprint it in the Deploy job.
I can't see how the Deploy job is getting the jar file. I would recommend using the Copy Artifact plugin that uses parameters - specifically a build number or perhaps the upstream-build - to retrieve the same file.
Related
I'm currently building scripts using Selenium Builder (which saves files as JSON) and i'm having a hard time running these scripts on VSTS. My question specifically is, can Visual Studio Team Services build JSON scripts and tie them in with its C.I.? If so, which approach must I take in order to do this / make it possible?
Thanks!
Here is my steps for your reference:
Deploy your own private build agent by following this link.
Configure the required environment on the build agent like Selenium Driver, Firefox so that the testing can be run on the build agent.
Upload the json file generated by Selenium Builder into VSTS Repository.
Create a build definition with two Command Line tasks: The first one runs npm install command to install se-interpreter:
And the second one run se-interpreter command to run the test in json file:
Queue the build, you will see the test been executed during the build:
I'm trying to implement a continuous deployment system and I seem to not be able to find a good answer for our problem.
We use Jenkins to run a maven build to generate our artifacts and deploy them to Nexus. I see a few projects that bundle up everything into a single war or tar file, extract one file per request from Nexus by name and deploy it to an application server, but this requires them to know beforehand what versions they have available.
My project has quite a few jars/wars/binaries among other artifacts, which don't get deployed using an application server. What we want to do is be able to do is pull any snapshot or release revision of the software out of nexus and either generate an install package or deliver it directly to a remote server.
Clarification: I want QA or development to be able to select a version from Jenkins; where Jenkins will poll Nexus for the available versions, then perform an automated deploy to a server from Nexus.
Is there an easy nexus/maven way to get software out to a testing system?
So, is there a way to poll nexus to determine what revisions are available through ant/ivy, Jenkins, maven, gradle? I'll write in something else if it helps.
I see that a similar question was asked here: How do I choose an artifact from Nexus in a Hudson / Jenkins job?, but it is as of yet unanswered 9 months later.
Nexus gives you a standard HTTP browsing capability. You could browse the repository through HTTP and see what is available.
I still don't understand your Use Case though. If you know which versions of the project you want then what is the problem?
The easiest would be to write an installer pom.xml that has in it a ${} placeholder for the version you want for the artifacts then invoke mvn with mvn package -Dproduct.version=1.0.0
If you use a container, PAX has plugins that allow you to specific artifacts like mvn:myGroup/myArtifact/myVersion and it will auto pull from Maven.
Nexus isn't doing any magic. It's all well known paths on a URL of groups/artifactId/versions
I have a job in Hudson server A which builds an artifact and deploys it to Nexus. I have another job in a completely separate Hudson server B which needs to download the artifact and deploy it. This job is normally run manually, and the person running it needs to indicate which version of the artifact to deploy - they may not always want to deploy the latest version (e.g. to roll back to a previous known good version).
Currently, I achieve this by using a parameterized build, and require the user to pass in the artifact version number; the job then uses the Execute shell build step to run wget on a URL constructed using the parameter. This is error prone.
Ideally I'd like a plugin that lets the user browse the artifact versions in the Nexus repository and pick and choose the one to deploy, but I'm open to other suggestions. A plugin that also handles the download would be nice, but I can live without it as long as I can still get a string that I can use in shell commands.
I've looked through the available Hudson & Jenkins plugins around Maven style artifact repositories, but they all seem more concerned with pushing artifacts into repos rather than getting them back down.
I'm using Hudson's "Copy Artifact" in other jobs, to get artifacts from other Hudson jobs on the same server, but this doesn't work across different Hudson servers, which is why I've turned to Nexus (which we're already using anyway).
Does anyone have any suggestions?
I recommend using rundeck to execute your deployments.
There is a rundeck plugin for Nexus that enables rundeck to display a pull down menu of available versions in Nexus.
There is a rundeck plugin for Jenkins that can be used to invoke deployments using rundeck and kick-off post deployment jobs (like integration testing) inn Jenkins.
Oure teamcity server (6.5) configured to checkout sources from SVN. For some build proceess cases I need checkout previous successfully builded version(revision). Can teamcity do this? And if can, how to configure checkout?
It sounds like you're looking for TeamCity Snapshot Dependencies, with the "Only use successful builds from suitable ones" option.
You'd end up with two build configurations:
Performs initial builds on commit to SVN
Has a snapshot dependency on #1, so when this build runs (either automatically - via a trigger - or manually), it grabs the same sources as the last successful build of #1.
Both of the build configurations would use the same VCS root.
I have a bunch of Maven projects building in Hudson with Sonar sitting in the side-lines. Sonar gives me Sonar stats, FindBugs stats, and code-coverage.
I've noticed that regardless of if I use Sonar or if I use EMMA via Maven directly, the entire build cycle runs twice. This includes init (which in my case, reinitializes the database -- expensive) and unit tests (a few hundred -- also expensive).
How can I prevent this? I did a lot of reading, and it seems like this is due to the design of code-coverage plugins -- to keep uninstrumented classes separated from instrumented ones.
I've tried configurations like:
Maven runs: deploy, EMMA
Maven runs: deploy; deploy to Sonar on completion
The sonar documentation recommends running the sonar plugin in 2 stages:-
mvn clean install -Dtest=false -DfailIfNoTests=false
mvn sonar:sonar
The tests are bypassed in the first phase and run implicitly in the second stage.
A one line alternative is to run the following command:-
mvn clean install sonar:sonar -Dmaven.test.failure.ignore=true
but this will run the tests twice - as you have found.
To add to #Strawberry's answer, you could reuse the unit test reports instead of running them again. Refer to the section Reuse existing unit test reports in the sonar documentation
Once this is done, you can configure the following in Hudson
clean deploy sonar:sonar