Build date / time showing December 31, 1969 after upgrading from 1.596.2 LTS to 1.625.3

Marc Esher

unread,

Dec 21, 2015, 9:41:24 AM12/21/15

to Jenkins Users

Greetings all.

After upgrading from 1.596.2 LTS to 1.625.3 LTS, all my jobs are showing "Dec 31, 1969" as the build date in the build history.

It appears the reason is that Jenkins has switched from using a date/time-based directory in "builds" to a simple number-based directory, but even though the symlinks are correct, something appears to be causing Jenkins to no longer be able to understand what's what.

If I drill into one of these builds in the UI, it does have a lot of data: git revisions, env variables, console output, so it can at least read something about these builds... but the date/time is wrong.

Any advice for fixing this?

Thanks!

Steve K

unread,

Dec 22, 2015, 3:14:14 PM12/22/15

to Jenkins Users

Marc,

Did you ever resolve your problem? I have a feeling that my current upgrade HELL (just posted a plea for help on that) is related to changes in format.
If you haven't resolved it, sorry if I got your hopes up when you saw a reply :-(

Regards,

Steve K.

Marc Esher

unread,

Dec 22, 2015, 4:32:42 PM12/22/15

to Jenkins Users

Hey Steve,

I did not resolve this problem on 2 of the jenkinses. However, on a 3rd, I did a straight update from 1.596 to 1.625, and I did not experience this behavior, so I'm thinking that my original problem is not quite as described. It seems that the problem originated on the busted jenkinses in question during a previous update, from 1.596 to some other version, presumably in the 1.6 + range, but I'm just not sure.

On those busted servers, I have not figured out how to resolve the problem. The symlinks are all in tact, but Jenkins can't seem to figure out what to make of them.

Sorry I can't be more helpful.

Baptiste Mathus

unread,

Dec 23, 2015, 1:23:26 AM12/23/15

to jenkins...@googlegroups.com

Just a small hint, in case it can help get you forward: the date you have seems to match Epoch.

So I suppose at some point, the computed timestamp for the build is 0 (or defaulted to).

My 0.00002 cents.

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/9bed974c-fec2-4c14-b883-0940228ea411%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Marc Esher

unread,

Dec 23, 2015, 7:05:22 AM12/23/15

to Jenkins Users, m...@batmat.net

OK, I now see what's going on specifically in my case. Definitely one of those stupid problems that I imagine there's no way Jenkins could account for it, so if I really care about fixing it I think I need to script a solution.

Here's the deal: it's all related to the build format migration that happened between 1.596 and 1.597: https://wiki.jenkins-ci.org/display/JENKINS/JENKINS-24380+Migration, in combination with a system that's partially managed by puppet, and partially not.

The root cause of the builds in question showing the epoch is that their build.xml does not have a <timestamp> element.

In our case, the reason is this: during a normal patch cycle, jenkins was yum-updated to a newer version, and the migration described in that wiki page happened correctly. Then, sometime after, puppet ran, and our puppet at that time was configured to pin jenkins to 1.596, and so it downgraded jenkins. This cycle probably repeated one or two times (we simply didn't realize it).

And so now, in each job's builds directory, we have a mix of old and new format build.xml files. All the symlinks are correct, but the busted builds do not have a <timestamp> element.