You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
error: pathspec 'origin/v7.x-staging' did not match any file(s) known to git.
That's my fault, I guess, though I might be triggering a bug elsewhere. I deleted the unused (I thought) staging branches, since we'll never do a v7.x release again (and can make a staging branch if we really needed it).
But, I'm a bit confused, why should @richardlau 's PR, richardlau wants to merge 1 commit into nodejs:master from richardlau:11eol, be depending on the existence of v7.x-staging?
These lines are interesting, too. I suspect that the bot has no longer necessary (but still running) code that is checking whether commits cherry-pick clean onto LTS branches, except that I think we removed that feature (inability to cherrypick happens all the time, but doesn't mean they won't cherry pick when the whole branch is picked down), and we certainly don't care if commits don't pick clean onto unsupported release lines.
19:38:20.386Z DEBUG bot: backport to 7 failed (req_id=78c9fb30-87c9-11e9-88d8-ed216d688228, pr=nodejs/node/#28078, action=pull_request.opened)
19:38:20.387Z DEBUG bot: Should have added (but temporary disabled): dont-land-on-v7.x (req_id=78c9fb30-87c9-11e9-88d8-ed216d688228, pr=nodejs/node/#28078, action=pull_request.opened)
19:38:20.387Z DEBUG bot: processing a new backport to v6 (req_id=78c9fb30-87c9-11e9-88d8-ed216d688228, pr=nodejs/node/#28078, action=pull_request.opened)
I'm going to repush those staging branches, but I think this is indicative of a code cleanup needed in the bot.
With #237 rolled out, we luckily have more error details to work with:
Error: Expected 200 from Jenkins, got 403
at Request.request.post [as _callback] (/home/.../scripts/trigger-jenkins-build.js:70:17)
at Request.self.callback (/home/.../node_modules/request/request.js:185:22)
at Request.emit (events.js:189:13)
I'm not aware of anything that's changed on our end. There were some plugin security updates earlier this week but I didn't update them because they didn't seem to impact us. Maybe someone else did though. There's some updates queued right now so I've run them and restarted Jenkins. Maybe try again now to see if that's fixed anything. @phillipj can you log more information about the failed response where you got that 403? I see it's only taking response.statusCode, the body might be informative for these situations.
Thanks for the quick reply. Good point about also logging the body, snook it into master now (7ced2a7). I'll post an example later when I see this error happening again.
in the node-test-pull-request-lite-pipeline job, it has that build token (replaced here with xyz but it's a long random string). I suppose, given that error message, that you not only need the token but also user permission.
nodejs-github-bot is only a member of the bots and automation-collaborators teams in the GitHub org and neither of these are configured in Jenkins to say that it it has "Job/Build permissions".
I'm hesitant to just add one of those teams or the user itself to Jenkins without understanding how we got here. There's 3 obvious reasons that I see:
A Jenkins upgrade broke this permission model--perhaps, but I haven't seen evidence that it was upgraded at the time this stopped working or that Jenkins have changed anything, but someone could investigate this further i suppose, the Jenkins release notes might be the place to look.
A change in Jenkins permissions--I can't find evidence of this and I'm fishing through config.xml history on the server. Perhaps there's something in the node-test-pull-request-lite-pipeline that I'm not seeing but I'm pretty sure it defers to global security.
A change in team membership of nodejs-github-bot--someone with audit log access on the org (@sam-github maybe?) could look through and see what kinds of changes were made in the timeframe in question. Maybe it got removed from "collaborators"? Maybe there's some team hierarchy stuff going on here.
@mmarchini from the sound of your work related to nodejs/node#34089, this might suddenly start working again since the bot gets privileges enough to start CI? Or wouldn't that affect the existing Jenkins token the bot is already using?
Probably not worth reopening though, once we have the auto start via label on nodejs/node, collaborators will be able to add the label while opening the PR, therefore starting a full CI run right away :)
(we also have Actions now that make the -lite pipeline redundant, we might consider disabling that functionality if the bot starts autorunning -lite again)
Activity
phillipj commentedon Jun 5, 2019
Thanks for reporting!
You're definitively onto something, seeing this in the logs:
After that, the bot process dies and starts up again few seconds later.
Not sure if all the above is related to the fatal explosion at the bottom, but sharing those logs anyway.
sam-github commentedon Jun 6, 2019
That's my fault, I guess, though I might be triggering a bug elsewhere. I deleted the unused (I thought) staging branches, since we'll never do a v7.x release again (and can make a staging branch if we really needed it).
But, I'm a bit confused, why should @richardlau 's PR,
richardlau wants to merge 1 commit into nodejs:master from richardlau:11eol, be depending on the existence ofv7.x-staging?sam-github commentedon Jun 6, 2019
These lines are interesting, too. I suspect that the bot has no longer necessary (but still running) code that is checking whether commits cherry-pick clean onto LTS branches, except that I think we removed that feature (inability to cherrypick happens all the time, but doesn't mean they won't cherry pick when the whole branch is picked down), and we certainly don't care if commits don't pick clean onto unsupported release lines.
I'm going to repush those staging branches, but I think this is indicative of a code cleanup needed in the bot.
sam-github commentedon Jun 6, 2019
I pushed v6.x-staging and v7.x-staging. Perhaps the issue should be retitled?
richardlau commentedon Jun 6, 2019
Those log lines are from https://github.com/nodejs/github-bot/blob/b6e54da9741460fd85fda1931bfb3aeaaba4fc28/scripts/attempt-backport.js. Given that it references 7, 6 and 4 which are long EOL it either needs updating or removal:
github-bot/scripts/attempt-backport.js
Lines 9 to 12 in b6e54da
sam-github commentedon Jun 6, 2019
probably removal, along with
github-bot/scripts/attempt-backport.js
Lines 52 to 54 in b6e54da
github-bot/scripts/attempt-backport.js
Lines 24 to 41 in b6e54da
github-bot/scripts/attempt-backport.js
Lines 73 to 153 in b6e54da
richardlau commentedon Jun 6, 2019
So it looks like jobs are now attempted to start but something's still going wrong, e.g. nodejs/node#28098 (comment)
phillipj commentedon Jun 6, 2019
With #237 rolled out, we luckily have more error details to work with:
phillipj commentedon Jun 6, 2019
IIRC we've seen this happen before when changes has been made in Jenkins, including plugin upgrades, does that ring a bell to anyone in @nodejs/build?
rvagg commentedon Jun 7, 2019
I'm not aware of anything that's changed on our end. There were some plugin security updates earlier this week but I didn't update them because they didn't seem to impact us. Maybe someone else did though. There's some updates queued right now so I've run them and restarted Jenkins. Maybe try again now to see if that's fixed anything.
@phillipj can you log more information about the failed response where you got that 403? I see it's only taking
response.statusCode, the body might be informative for these situations.phillipj commentedon Jun 7, 2019
Thanks for the quick reply. Good point about also logging the body, snook it into master now (7ced2a7). I'll post an example later when I see this error happening again.
phillipj commentedon Jun 7, 2019
The 403 response body consists of HTML, where the only human readable message I see is:
@nodejs/jenkins-admins help?
rvagg commentedon Jun 11, 2019
sorry, I'm not sure what's up with this, the bot has this config:
in the node-test-pull-request-lite-pipeline job, it has that build token (replaced here with
xyzbut it's a long random string). I suppose, given that error message, that you not only need the token but also user permission.nodejs-github-botis only a member of thebotsandautomation-collaboratorsteams in the GitHub org and neither of these are configured in Jenkins to say that it it has "Job/Build permissions".I'm hesitant to just add one of those teams or the user itself to Jenkins without understanding how we got here. There's 3 obvious reasons that I see:
Aside from that 🤷♂
jenkins: don't post PR comment on errors when triggering Lite-CI
jenkins: don't post PR comment on errors when triggering Lite-CI (#241)
phillipj commentedon Jul 30, 2020
@mmarchini from the sound of your work related to nodejs/node#34089, this might suddenly start working again since the bot gets privileges enough to start CI? Or wouldn't that affect the existing Jenkins token the bot is already using?
mmarchini commentedon Jul 30, 2020
Ahhhh, I thought I saw an auto started CI in one PR. Yeah, my guess is this should be working now.
mmarchini commentedon Jul 30, 2020
There it is: nodejs/node#34558 (comment)
The bot is alive!
phillipj commentedon Jul 30, 2020
Hooray! Thanks for diving into getting those privileges fixed 💯
mmarchini commentedon Jul 30, 2020
For some reason, this only worked once 🤔
Probably not worth reopening though, once we have the auto start via label on nodejs/node, collaborators will be able to add the label while opening the PR, therefore starting a full CI run right away :)
(we also have Actions now that make the -lite pipeline redundant, we might consider disabling that functionality if the bot starts autorunning -lite again)
mmarchini commentedon Jul 31, 2020
Opened a PR to remote Lite-CI since it starts but fails instantly.