Check why http://jenkins.ovirt.org/job/ovirt-node-ng_master_build-artifacts-el7-x86_64/447/ wasn't time triggered for months

Description

The follow job http://jenkins.ovirt.org/job/ovirt-node-ng_master_build-artifacts-el7-x86_64/447/ is defined to run nightly (00 04 * * *) but for some reason didn't run for 9 months.

We need to investigate why it didn't run and maybe find some clues in the logs.

cc

Activity

Show:

Former user July 12, 2017 at 11:06 AM

retention history changed, closing

Eyal Edri June 27, 2017 at 12:36 PM

I've sent https://gerrit.ovirt.org/#/c/78707/ to increase the build history for now.

Eyal Edri June 26, 2017 at 6:34 PM
Edited

The retention policy is defined in the templates (under jobs/conf/yaml/templates), look for

"{project}_{version}_build-artifacts-{distro}-{arch}{_big_artifacts}"

Former user June 26, 2017 at 2:17 PM

I don't see any retention settings in the job configuration yaml and not entirely sure where they're inherited from.

As for build #97 - it is marked with the "keep this build forever" tag, that's why it was not deleted.

Former user June 26, 2017 at 1:34 PM

There were more than 2 builds in the job's history after Sep 2016... why did it save that single job from 2016 ?

Eyal Edri June 26, 2017 at 1:28 PM

Can you check what is the current configuration in YAML for keeping history for this job?

Former user June 26, 2017 at 1:26 PM

This job has "Max # of builds to keep" equal to 2 so all older builds are deleted by Jenkins itself. I do not see any "max-total: 2" configuration in our YAMLs so not sure when this change was introduced. Recent job config history doesn't have anything related to changes in this parameter:
http://jenkins.ovirt.org/job/ovirt-node-ng_master_build-artifacts-el7-x86_64/jobConfigHistory/

Former user June 25, 2017 at 9:00 AM

Yes, is right, I think the deletion messed up lastSuccessful, making it point to some old version. However, using the rpm would mean a bigger change, and it would take a little more time to run (extract the rpm etc). I think that the best way to fix this, is to copy the squashfs from its original place to the exported-artifacts dir with a timestamp, so instead of cp <squashfs> exported-artifacts, it would be something like cp squashfs exported-artifacts/squashfs-<builddate>, and let image-ng continue to pick up the squashfs by a build number.

Fixed

Details

Assignee

Reporter

Priority

Created June 22, 2017 at 3:43 PM
Updated August 3, 2017 at 3:02 PM
Resolved July 12, 2017 at 11:06 AM