I have started to use jenkins to build my project. I build my project yesterday and it took me 26 sec to build my flex sdk. I build the same file today and it took me 19 min to build the same file. Could anyone explain how this is happening ? I am trying to optimize my build scripts and I am not able to understand if there is something wrong with my build file or with jenkins.
This is the build that took 19 min
This is the build that took 26 sec
This is my second build running after the first one and the part of MXMLC Compiles took around 27 min out of the total 34 min
Is this happening consistently? Was your system perhaps overloaded when the second build occurred? e.g. A backup running or some CPU-intensive process?
If you install the Timestamper plugin for Jenkins, you will be able to see which parts are taking longer.
Is your Jenkins system on a box all by itself? Is this on Windows?
On Windows systems, files can become locked for all sorts of reasons. I've had problems just because I had a Windows Explore window open up to a directory where Jenkins wanted to overlay a file. Jenkins froze up until I closed my Explorer window. Could this be an issue?
Where is the task being delayed? Install the Jenkins timestamper plugin, and that'll show you what tasks are taking so long. From there, you can narrow down your investigation a bit.
Related
I have an "official" Jenkins running on ServerA, and a copy (copy of the .jenkins folder) that runs on ServerB and is slated to become the new official Jenkins, so we are testing it. Both installations are active.
I find today that, when I try to start a build on the new server, it complains that the build number 704 already exists, and indeed it does. So I wonder why it didn't pick a fresh number. The number it picks (and fails) is a number that was indeed used on this new server nine days ago. That build ran to success.
As a test, I deleted build 704, and retried it. It then picked 705 as a number, and is now running. However a previous and conflicting build may be significant and not to be deleted, so this is not really a workaround....
Thanks for any clues!
We are using the new DevOps build server (on premise) to build a .Net project using the Visual Build Step. When we run the build we get the following error and the build stops during the checkout step:
TF400889: The following path contains more than the allowed 259 characters "long path" Specify a shorter path.
We used to get this error in the older XAML builds but the build continued running. Is there a way to ignore this error in DevOps as well?
build stops during the checkout step. Is there a way to ignore this error in DevOps as well?
No, there is no way to ignore this error. Since it cause the build failed to check out source directory for future tasks.
For this kind of long path issue, the common workaround is to shorten the build path on the server.
For example: instead of \xx\Build\Drop\ProjectName, just use \xx\Build\Drop (or \xx\Builds) since the project name is also in the build name.
Windows imposes the 25x character limit, so if you are running against windows-based agents, you will definitely still run into that. This is not related to XAML or new build system in TFS.
Your best bet would be to refactor you application so it doesn't have long paths but if you are running your agent on windows 2016 or better, you can always try this: https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/ (article mentions Windows 10 but it works for Server 2016 also).
Good luck,
Etienne
I am completely new to using Jenkins. I'm going through some "step-by-step" videos by RagHav Pal and have reached the point where I have made a batch file that runs command lines when I hit the "Build Now" link. It has been established in the "Build" and "Execute Windows batch command" area of the configuration "Build Environment" tab.
The build is happening as expected, and I do expect some of the Robot Framework Test Cases to fail (which they do). The problem is this: When the build is happening, it is queueing up another build right behind it. It then runs that build too when the first one is done? This queueing continues. Builds keep on building and I have to hit the "x" on the queued build to stop this madness.
I have no idea why it's rebuilding, nor do I know what I've done to cause this. I need the details please, if anyone can help. I want one build... period! Nothing more.
THINGS I HAVE TRIED:
I've tried restarting Jenkins after upgrading any plugins that looked like they needed upgrades.
I've started Jenkins localhost:9090 using Microsoft Edge and discovered I'll get endless builds. However, if I start Jenkins localhost:9090 using Chrome browser I only get 2 builds. Why this difference? I want 1 build only.
I've taken a look at my java folder to see what is there. It has "jdk-12.0.1" which I believe is used for Eclipse. It has "jdk1.8.0-221" and "jre1.8.0-221" and I renamed each of these folders to something else and restarted Jenkins from command line to see which one is getting used. It is using the "jre1.8.0-221". Should I be running the jdk? Dunno? I put everything back the way it was.
I verified the "Poll SCM" check box is not selected.
THE BATCH FILE:
c:
cd C:\Users\TestLab\Desktop\Workspaces\JenkinsWorkspace\RobotFramework\GoDirectProject1
robot GDTest/GoDirectSuite1.robot
echo Completed
EXPECTED AND ACTUAL RESULTS:
I'm expecting the build to happen one time and stop
Actual results are as explained above in "Summarize the Problem"
I use HPE Automation Tool plugin in Jenkins to run UFT(CI/CD). In the configuration I have put a timeout of 36000 sec(10 hours). Ideally UFT should terminate after 10 hours but it is not terminating and keeps on running.
At the same time if I change the timeout configuration to 2 minutes it works like a charm. But the project that I am working on needs that 10 hours timeout configuration.
UFT version 14.03 is installed in a windows server and the scripts run there.
HPE Automation Tool Plugin version used is 5.2.
Can someone please provide me their inputs, what may the issue?
The plugin uses the QuickTest.Application COM Object to start and control the Test Robot(UFT). I had many issues with UFT running more than 2 hours without any restart (I had my own script driving it) - so I wouldn't assume it is an issue of the Plug-in but of UFT. You could try investigate it further but hey let me tell you my tests:
Have some long tests and run them directly from UFT (Do they run for 10 hours without restart? - mine didn't)
Do the same but drive the execution via a script.
If all those 2 is OK, well then you can assume it is the Plug-in, but again my personal experience with the 2 ways mentioned above led me to the conclusion that it is UFT and not the driver scripts.
What I can propose as an alternative:
Have milestones (Save some Item IDs, critical data somewhere (DB, Files) - restart UFT regularly and reload data stored in the milestone
I have a multi-module maven project that I'm building with Jenkins called MyApp. I also have another maven project that depends on MyApp, and this project runs integration tests on MyApp.
In Jenkins, when I view the status of the MyApp project it successfully displays a list of previously run builds and I can click on them to find out more information (and view the console output).
However, the integration test project, while it does build properly, it only displays previously run builds for about 5 minutes, at which point something happens and jenkins completely forgets the build ever ran.
On the filesystem, I am able to cd to:
/usr/share/tomcat6/.jenkins/jobs/My App Integration Test/builds
and ls reveals
me#myserver:/usr/share/tomcat6/.jenkins/jobs/My App Integration Test/builds$ ls
1 2 2013-01-24_16-46-59 2013-01-24_16-51-58 2013-01-24_18-05-09 2013-01-24_18-58-46 3 4
that all my previously run builds are right there, where they should be.
Jenkins has a "discard old builds" feature in its project configuration page, but I obviously have it unchecked.
I'm running jenkins in tomcat6 on Ubuntu.
Help please?
Jenkins has resolved this issue as of 1.505 I recommend everyone upgrade who does not wish to switch from Jenkins back to Hudson.
This can be done through the GUI via Manage Jenkins->Upgrade to Latest (Note for this to work you need to have the appropriate permissions for Jenkins)
More information can be found here For linux users aptitude update or yum update jenkins should also work for you.
I have jenkins running with 1.517, still facing the issue if the number of builds goes more than 65 without discard option. Found that reload configuration bring back the build history.
I've seen this issue and have always been able to resolve it by following these steps:
Going to \\[buildmachine]\C$\Jenkins\jobs\[jobname]
Removing the builds folder.
Removing shortcuts to lastStable and lastSuccessful.
Open file nextBuildNumber and change the number to 1.
Then build new jobs and they no longer disappear.
As mentioned by Dave Bacher, this appears to be a bug in Jenkins. I switched over to Hudson and problem fixed!