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"
Related
So I'm running into a specific issue, I have a Jenkins Declarative Pipeline (from an SVN hosted Jenkinsfile) that is configured to not run concurrent builds and abort previous builds when a new build is triggered.
This works perfectly fine, however the problem I am running into is that Jenkins will re-checkout the whole repository to an #2 suffixed workspace directory for the subsequent build (this ONLY happens when a build is automatically aborted after a new one is triggered, if the first build ends successfully, it re-uses the same directory).
I've seen a ton of threads stating that this is by design, but from what I can see that's only when concurrent builds are enabled, but since it's not I'm confused as to what could cause Jenkins to not re-use the same workspace directory?
If the "why" I require this is necessary, I have a few large repositories (for Unreal Engine games specifically), that I need to build and as an optimization measure for the time in compiling, cooking and uploading the game, it makes perfect sense to cancel old builds but instead Jenkins decides to clean checkout 10+GB of game code and assets (20+ in the case of some other games) in another folder becuase it can't reuse a folder that's not having a job/build executed in it already 😅.
Happy to accept all possible solutions/suggestions as I'm getting a lil' tired of pulling my hair out.
I was facing the same issue with my pipeline. I tried deleting the aborted builds and restarted jenkins. I also deleted the #2 directories in my workspace and only kept the main directory out there. Post this,I didn't face the same issue. This could happen because of the jenkins cache. Make sure that your workspace is correctly reflecting the directory name mentioned in your jenkins file.
I'm trying to build our code through jenkins. I set it up 4 days ago and everything worked back then, but now every build fails. At first I thought it was because of the Jest testing I added (jest kept hanging instead of stopping) but I fixed that with --forceExit and the problem still exists.
With every build, it seems like Jenkins is crashing silently. I couldn't find any useful logs or anything. What is weird though, is that I tried to execute the commands through ssh in the jenkins folder where the project was placed by jenkins. When I did that, the npm install was really slow and the whole server was hanging. There are two other projects running from that server with nodejs, one with keystonejs that crashes every time this happens, the other one is plain express and had no problems. Any idea what can be the problem here?
EDIT: It's also happening more randomly and I couldn't connect to my server for a while through ssh or any other possibility.
If is simple what you need to do, then don't use jenkins, is just to heavy.
Instead build an sh file that builds what you need, the down side of this is that you have to execute it by hand when you need to build.
I ran a build yesterday, hoping I would read some logs today.
I came today, and got an error 404 when trying to access the build. Strange.
Running another build, shows my build actually did run, but it is unreachable.
Is there a way to get my hands on the logs?
Notice build #10 is missing, even though it did start.
Probably a windows update is to blame for this.
The broken link is http://192.168.80.10:8080/job/Dev_git/10
More information on a run can usually be found using the context menu under Console Output. This is only accessible if you have the correct permissions set in Jenkins.
This of course does not work, if a build is missing. One reason could be that your Jenkins is configured in a way that only a certain number of historic builds are kept, see Build History Missing in Jenkins for an explanation how to deal with that.
However, your case seems to be different, because a build in the middle of the history is missing. For this, I suggest to look around in the jobs directory of your Jenkins installation where it stores all the configuration and run data.
References
https://wiki.jenkins.io/display/JENKINS/Administering+Jenkins
Where does Jenkins store configuration files for the jobs it runs?
We're using TFS Build and are having the TFS Build process run tests through a Test Controller on a Test Agent on a remote machine. We do this via a testsettings file in which we specify the test controller. This testsetting file is specified as an argument in the default TFS 2012 Build process template.
Everything works fine. However, our build takes about an hour. In the event that a test should fail because of an environmental issue (so in the event where it fails only on the test agent and not on our Dev machines), I'd like to be able to re-run the tests and diagnose the environmental issue that happened. However I can't seem to figure out how to do that WITHOUT re-running the entire build. Once the environmental problem is fixed, I'd like to be able to re-run the tests again to make sure everything is ok. I'd like to do all this without re-running the entire build. Ideally when I re-run my tests they should run in as similar a configuration as possible as to when TFS Build runs the tests.
Is there a way to do this? Is using MSTest command line an option to re-run the tests? If so, how do I know which arguments to pass to it? Ideally i'd want the same arguments TFS passed to the QTAgent process which ran the tests?
Create build specific, based on sequential workflow specific whose you delete from designer WWF all activities that don't need.
I suggest theses steps : 1. Select link 'Create Build Definition' 2.Create Process Template by copy pasting on Source Control, 3.Open your copied Workflow on designer 4.Delete all activities that you don't need. 5.Finish by associating this workflow to build definition (Select Process Tab)
The easiest way to prevent the whole build from running is to set "Clean Workspace" to None.
That means if you want to re-run the tests you can just queue the existing build definition manually, change to the Parameters tab and set Clean Workspace to None before click the "Queue" button.
In this case existing build outputs remain as well as source code files that have not changed since the most recent build (by performing a tf get without the /all switch).
It's probably not exactly what you want because if there were some check-ins since the most recent build the changed source files will be fetched and built.
But if it is not important for you to re-run the tests using exactly the same build output each time it could be a good solution for you since it usually reduces build time significantly.
One way for you to possibly do this is:
Open the build that had failed tests in Visual Studio
Scroll down to the test runs section.
Click on the failed test run. The Test Results window should open.
Select the failed tests you want to rerun.
click the "Run checked tests" button
Supposedly this should work: vstest to tfs logger. I can verify that the test are run and published to our tfs, but I could not see the test result on the tfs build page only using the link that is produced (the one with mtm as protocol)
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!