I have a jenkins job that is polling my TFS server. My TFS Server lives on AWS. It is finding changes that are happening in the future and starting my job. Here is what is displayed in the TFS Polling log.
Started on Sep 8, 2016 10:46:09 AM
Done. Took 0 ms
Changes found
Inside of my build console for this job shows this which makes me believe something is running on GMT time as it is exactly 6 hours ahead of my current timezone (MDT).
Querying for remote changeset at '$/XXXXXXXXX/Three/Dev' as of 'D2016-09-08T16:46:15Z'...
Query result is: Changeset #98532 by 'XXXXXXX' on '2016-09-08T13:58:27Z'.
It's stuck in an endless loop because that value is always in the future. I have checked everything to make sure it is on the correct timezone (Jenkins Master, Jenkins Node(slave), the Linux box Jenkins Master is installed on, the TFS server (front and backend)) I thought about setting the timezone for jeknins to GMT but that would mean all the jobs we have that run at certain times of the day would start to fail.
From my test, the date and time in Console Output of Jenkins build is GMT time by default. There is nowhere to change this. If you check TFS log, you'll find it also use GMT time in log file and no where to change this.
Related
I have Git Poll SCM set to every minute ( * * * * *). It stopped working a couple of days ago.
Based on the Git Polling Logs: Started on Jun 9, 2022 7:31:00 PM
It seems to be working on other jobs fine. Already checked the logs and don't see any issue.
I can build the job manually and it builds all those new SCM changes.
Any idea why?
TFS 2015 update 3 test agent goes idle/sleep every time I queue a build. I have automated UI build running test on my system itself. I have to manually refresh the agent every time.
Couple of other issues-
1.Access is denied error with WinRM even though nothing has been changed. This comes in subsequent runs. Will have to delete and re configure agent from start when this happens.
2.Agent is locked or sleep.
Please help.
Is there a way to log who ordered a Jenkins restart? The log right now just denotes that a restart happened. I would like something like
Mar 30, 2015 9:57:01 PM INFO: Safe-restart started by GregWringle.
Is there anyway I can implement this?
Jenkins does this various restarts, but for restart after installing a plugin it puts the user as anonymous. There's an audit plugin that records the user name.
Suppose i have set a Jenkins job from 12 pm to 1pm. Let us say job has been started. Now suppose Administrator has set Jenkins to be restarted at 12:30 PM. What would happen- will my script gets paused or gets failed?
Surely your builds will abort if jenkin is going for a restart/shutdown. I have seen some cases where you lose even the build log for that particular build.
(jenkins_url)/safeRestart. This will allow all running builds to complete.
(jenkins_url)/restart will force a restart without waiting for builds to complete.
On TFS 2010 we set up a build script to automatically run and deploy to our test environment no more than every 4 hours. So the trigger of the build definition is "Rolling builds - accumulate check-ins until the prior build finishes" with the check box checked for "Build no more often than every [240] minutes". The way I'm interpreting this is that if a build happens at 16:25, and there's 3 check-ins in the next 30 minutes (the last happening at 16:52), then the next build will happen at 20:25.
The issue we're seeing is that if this sequence of events happens on a Friday, then the next triggered build doesn't occur until Monday morning. We do have two build agents on their own separate virtual machine from TFS, but all machines are up and running 24/7.
There's nothing that anybody on the team is aware of that would cause this behavior, so we're at a loss for why we're seeing it. Are we simply misunderstanding the meaning of Rolling Build, or is there configuration setting we forgot to check?
EDIT: For what it's worth, the entirety of the build & deployment process takes all of 90-120 seconds. So there were not any check-ins that occurred while it was still building.
The Accumulate check-ins means that when you check-in a changeset, if there is no build of this build definition in 240 minutes, TFS will queue a build automatically. But if do not check-in a changeset, no builds will be queued.
Builds should be triggered as you wrote. 3rd build should be triggered after the first check-in after 20:25 build not before 0:25 on Saturday. :)
Try to check if changesets were not checked into the location cloaked in the build definition workspace (or checked into the location not mapped by build definition workspace).