Job builds timestamps have changed to DEC 31, 1969 or Jan 1, 1970

Article ID:218434707
2 minute readKnowledge base

Issue

  • Jobs' build timestamp have been changed to "Dec 31, 1969", or "Jan 1, 1970".

  • This issue have been found after moving jobs to an new version of Jenkins by an update or by a migration.

Environment

  • CloudBees Jenkins Enterprise (upgrading from 1.597)

  • Jenkins (upgrading from 1.597)

Resolution

For Jenkins releases after February 2015 (Jenkins versions 1.597), the $JENKINS_HOME layout suffers a change: builds are now keyed by build numbers and not timestamps in $JENKINS_HOME/jobs/<JOB_NAME>/builds/<BUILD_ID>/build.xml. Please have a look at JENKINS-24380 Migration for more information. Whenever a newer version of Jenkins starts with an older $JENKINS_HOME, the necessary changes happen automatically during startup. Old build records are converted to the new layout. This fact explains possible delays on the startup time.

Most of the cases, this issue occurs when Jenkins is upgraded past 1.597, downgraded to a version before 1.597, then upgraded again.

The build.xml conversion has been done correctly and timestamp tag is equal to 0 <timestamp>0</timestamp>, which equates to the Unix epoch (December 1969 in Julian date format).

To correct this, follow these steps:

  1. Visit https://$JENKINS_URL/JENKINS-24380/ and copy the un-migration instruction.

  2. Shut down Jenkins completely.

  3. Run the command as instructed by the step above.

  4. Start Jenkins

When you start Jenkins, it may take a while because it will be repopulating each build.xml file. Please make sure you have a backup in place before performing this fix.

Having done that, a Groovy scripts can be applied in order to fix this issue by populating the timeStamp parameter with the value in the startTime parameter. Be aware that this proposed fix is just valid when the start Time parameter in the build.xml has not been damage, so it is not equal to 0.

timeStamp is when the build was kicked off in Jenkins, and startTime is when the build itself actually started, so there is usually a difference of a few seconds. Please, back up your Jenkins by using Backup Plugin or ThinBackup Plugin before running the following script.

To run it, navigate to $JENKINS_URL/script and paste the script below:

jobs = Jenkins.instance.getAllItems(AbstractProject.class)
jobs.each { j ->
  println 'JOB: ' + j.fullName
  numbuilds = j.builds.size()
  if (numbuilds == 0) {
    println '  -> no build'
    return
  }
  j.builds.each{
    if(it.timestampString == '<Wrong_TimeStamp>'){
    	it.timestamp = it.getStartTimeInMillis()
        it.save()
  	}
   }
}

<Wrong_TimeStamp> is the flag used for updating the wrong builds timestamps. For instance '46 yr' . In order to get timestamps string print, run first:

jobs = Jenkins.instance.getAllItems(AbstractProject.class)
jobs.each { j ->
  println 'JOB: ' + j.fullName
  numbuilds = j.builds.size()
  if (numbuilds == 0) {
    println '  -> no build'
    return
  }
  j.builds.each{
    println it.timestampString
   }
}
In case you have a Distributed Configuration based on agent.jar files, those agents.jar need to be updated. To get more information about this, please have a look at the chapter Write your own script to launch Jenkins agents on [Distributed Builds documentation] (https://wiki.jenkins.io/display/JENKINS/Distributed+builds)