Bug #11803

Wrong file permissions sometimes prevent Jenkins jobs from being created or updated

Added by anonym 2016-09-16 12:57:24 . Updated 2016-12-06 13:52:19 .

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Continuous Integration
Target version:
Tails_2.9.1
Start date:
2016-09-16
Due date:
% Done:

100%

Feature Branch:
Type of work:
Sysadmin
Blueprint:

Starter:
Affected tool:
Deliverable for:
280

Description

Today I’ve pushed two new branches, feature/11802-tor-browser-6.0.5 and feature/10733-reverted, but no job was created for either of them even hours later.

Subtasks

History

#1 Updated by intrigeri 2016-09-17 03:47:54

/etc/jenkins_jobs/jobs.git/index was owned by root again so the cronjob could not update this clone.

#2 Updated by intrigeri 2016-09-19 02:35:04

  • Target version changed from Tails_2.6 to Tails_2.7

#3 Updated by intrigeri 2016-09-24 05:01:35

  • Subject changed from New build jobs are not being created on Jenkins to Wrong file permissions sometimes prevent Jenkins jobs from being created or updated

#4 Updated by intrigeri 2016-09-24 05:17:46

It has happened again today. I checked the logs around the mtime of .git/index and the only thing in there around that time was a Puppet agent run, so I’m starting to wonder if the vcsrepo module might be doing something as root.

#5 Updated by intrigeri 2016-09-24 05:25:39

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10

Tried something in puppet-tails commit 7ac05a6. If that’s not enough, I think I’ll simply add a cronjob that fixes the permissions, or ACLs to ensure that the jenkins user gets & keeps the access it needs on .git/index.

#6 Updated by intrigeri 2016-09-24 05:26:28

bertagaz: since this is your turf, I would not mind if you had a look. With a fresh mind and another set of eyes, you might have ideas that I’ve not.

#7 Updated by intrigeri 2016-10-01 05:25:40

  • Target version changed from Tails_2.7 to Tails_2.9.1

I’ve not seen that happen again. I’ll keep an eye on it. I expect that one of us will notice and tell us if it happens again, so I’m postponing this to 2.8 so that I can double-check then and close this ticket if the problem never happened again.

#8 Updated by intrigeri 2016-11-03 10:04:47

  • Deliverable for set to SponsorS_Internal

#9 Updated by intrigeri 2016-12-06 13:52:19

  • Status changed from In Progress to Resolved
  • Assignee deleted (intrigeri)
  • % Done changed from 10 to 100

Didn’t happen again anymore I applied a tentative fix 2 months ago, so I think we’re good.