Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Fix [JENKINS-34281] by running shutdown as system user so we can see items to persist them in queue - Mk 2 #2276
Too long; Didn't read summary: Jenkins wasn't running some forms of shutdown as the system user, and when we removed anonymous read access as part of the secure-out-of-the-box PR (https://github.com/jenkinsci/jenkins/pull/2042/files#diff-f65b8a70854ca1cc6c12397eee54d279R62) then it could no longer see build items to persist them.
I asked Sam to file in this branch. Still undecided whether I consider this safe enough to merge. I think it is a severe problem if it's a regression.
To anyone with a queue they want saved, yes. Remember how "You can restart Jenkins and your pipelines will survive!" is a big feature of Pipeline? It becomes much less impressive if Jenkins forgets what's in the queue at the same time.
Compare this to the OS X Yosemite -> El Capitan, or Windows XP -> Windows Vista/7 : people perceived these upgrades as problematic and buggy, largely due to security improvements which also technically weren't regressions. Also, to be clear: the original issue was introduced between Jenkins 1.609.3 and 1.625.3
Consider also that with 2.0 we're likely to see a far larger than normal influx of users trying out fresh installations, and as mentioned, pipeline durability is likely to be front-and-center. Given the significant 2.x changes, I imagine some of these will be people trying out fresh installs before upgrading their 1.x systems.
With regards to ACL.impersonate: it's present in all the other paths triggering the cleanup method, this was just an oversight, so it is safe to say it works. Given this and the fact that the change is scoped to shutdown behavior only, the risk level is far lower than normal.
Pending a decision from @daniel-beck on this (I can re-cut the PR to apply against master), but for those reasons I would argue against postponing this to 2.1
I decided to leave this out of 2.0. I do consider this an important fix we need to deliver ASAP, as this does constitute data loss and is at the same time a regression between 1.609.3 and 1.625.3.
However, I was unable to find bug reports about this, indicating it's not perceived as a real problem. This also will only affect new installs, as upgraders likely already have the problem.
Delivering the fix in 2.1 looks like a reasonable compromise.