Details
-
Bug
-
Status: Resolved (View Workflow)
-
Blocker
-
Resolution: Fixed
-
Ubuntu 14.04, 15.04, 15.10
Windows Server 2012 R2
Description
After upgrading to 1.651.2 security update, jobs are getting this error:
FATAL: org.acegisecurity.providers.UsernamePasswordAuthenticationToken cannot be cast to org.jenkinsci.plugins.GithubAuthenticationToken java.lang.ClassCastException: org.acegisecurity.providers.UsernamePasswordAuthenticationToken cannot be cast to org.jenkinsci.plugins.GithubAuthenticationToken at org.jenkinsci.plugins.GithubSecurityRealm.loadUserByUsername(GithubSecurityRealm.java:644) at hudson.model.User$UserIDCanonicalIdResolver.resolveCanonicalId(User.java:1049) at hudson.model.User.get(User.java:395) at hudson.model.User.get(User.java:364) at hudson.plugins.git.GitChangeSet.findOrCreateUser(GitChangeSet.java:374) at hudson.plugins.git.GitChangeSet.getAuthor(GitChangeSet.java:435) at hudson.model.AbstractBuild.getCulprits(AbstractBuild.java:350) at hudson.model.AbstractBuild.getCulprits(AbstractBuild.java:346) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:672) at hudson.model.Run.execute(Run.java:1763) at hudson.matrix.MatrixRun.run(MatrixRun.java:146) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:410)
Also, in the "Manage Old Data" section, I see very suspicious stuff:
hudson.matrix.MatrixRun Team » carbon-c-relay » precise #2 1.653 hudson.matrix.MatrixBuild Team » proj #22 1.653 hudson.model.FreeStyleBuild Team » other #255 1.653
Why is there any data in 1.653 format if I'm using 1.651.2 (and upgraded from 1.651.1)?
Is there any archive with old debian packages to be able to downgrade? All our jobs are broken now. Thanks!
Attachments
Issue Links
- is duplicated by
-
-
- Closed
-
- is related to
-
-
- Resolved
-
Activity
Update:
I printed authentication.getCredentials().toString() and so see "SYSTEM" from my previous patch.
teilo You are right. There is mismatch between my trace and code v0.24. Possibly it is my bad and I forgot to restart Jenkins.
But now I applied patch to code from master. In my case I should get UserMayOrMayNotExistException. I'll check it.
Andrei Kovrov
added a comment - - edited Update:
I printed authentication.getCredentials().toString() and so see "SYSTEM" from my previous patch.
teilo You are right. There is mismatch between my trace and code v0.24. Possibly it is my bad and I forgot to restart Jenkins.
But now I applied patch to code from master. In my case I should get UserMayOrMayNotExistException. I'll check it. 
Sam Gleske
added a comment - rawmind According to your screenshot it looks like you're in the plugin updates section of the configuration. Meaning you're running 0.22.2. i.e. you haven't upgraded yet. I also confirm that the casting exception occurs in line 644 of github-oauth-0.22.2.
Sam Gleske
added a comment - rawmind According to your screenshot it looks like you're in the plugin updates section of the configuration. Meaning you're running 0.22.2. i.e. you haven't upgraded yet. I also confirm that the casting exception occurs in line 644 of github-oauth-0.22.2. Andrei Kovrov
added a comment - sag47 I confirm that is my fail and I didn't restart Jenkins, but issue still exists in v0.24. My described update above is actual.
Steps to reproduce:
- create job with git repo
a) specify Repository URL,GitHub project URL, Branch and set "Build when a change is pushed to GitHub" on Source Code Management
b) create Post-build Actions-> Editable Email Notification and specify (Project Recipient List =<your_email>, Project Reply-To List=$DEFAULT_REPLYTO, Default Subject="${GIT_COMMIT}-$BUILD_STATUS" (without doubleqoutes), Content Type =HTML, Default Content = $DEFAULT_CONTENT) - do commit and push any change to <branch> described in (a)
Empirically way I found, that job begins to fall about hour after Jenkins was started.
Andrei Kovrov
added a comment - sag47 I confirm that is my fail and I didn't restart Jenkins, but issue still exists in v0.24. My described update above is actual.
Steps to reproduce:
create job with git repo
a) specify Repository URL,GitHub project URL, Branch and set "Build when a change is pushed to GitHub" on Source Code Management
b) create Post-build Actions-> Editable Email Notification and specify (Project Recipient List =<your_email>, Project Reply-To List=$DEFAULT_REPLYTO, Default Subject="${GIT_COMMIT}-$BUILD_STATUS" (without doubleqoutes), Content Type =HTML, Default Content = $DEFAULT_CONTENT)
do commit and push any change to <branch> described in (a)
Empirically way I found, that job begins to fall about hour after Jenkins was started. rawmind that sounds like a different issue. Can you create a new issue for it please?
loadUserByUsername is called for cases when there is no corresponding user, or a user is not attempting to log in.
It is used by Jenkins to test if user zyx is a authenticated user (ie one in GitHUb) vs a virtual user (e.g. from an SCM commit).
The previous fix is enough and the stack from rawmind shows that he is not running the 0.24 release (did you restart Jenkins after upgrtading?) as there is no cast on line 644 at all so this is an impossible exception stack according to the code in github..