[JENKINS-72268] Missing permission due to desync with cache #256
Conversation
In case of impersonation the gh variable and the usersByTokenCache could be de-sync, leading to token not able to connect. Could be related to JENKINS-72209 as well.
…s expected from the plugin
|
Hi, @Wadeck and @MarkEWaite I believe this change introduced a huge performance regression. When installing 596.v0646c4a_0a_962 I have seen 20x performance degradation for every GH-based build pipeline. Can you please take a look and fix / revert this please? Thank you. |
| @@ -504,6 +504,9 @@ private GHMyself loadMyself(@NonNull String token) throws IOException { | |||
| // Also stick into usersByIdCache (to have latest copy) | |||
| String username = ghMyself.getLogin(); | |||
| usersByIdCache.put(username, new GithubUser(ghMyself)); | |||
| } else { | |||
| // force creation of the gh variable, esp. in case of impersonation | |||
| getGitHub(); | |||
There was a problem hiding this comment.
I think this is the cause of the performance degradation
There was a problem hiding this comment.
@lprimak can you describe more about your environment and usage?
- In what ways to you use auth? Just oauth web or GitHub personal access tokens, too?
- How are your jobs organized? Are they in folders or grouped into views? What columns do you have enabled on the landing page if Jenkins for the All view?
- Where were performance issues most noticeable?
- How many users?
- How many jobs and can you break down numbers by job type?
Hopefully, with enough info, it can be reproduced and fixed upon reproduction. Any answers you provide can help us figure out a performance profile and attempt to emulate your environment.
There was a problem hiding this comment.
Also if you could describe how you evaluated the 20x performance reduction it will give us hints of where to look as a root cause. It's not always just the contributed area that could be the root cause, it's possible an unrelated area of code could trigger the conditions for this performance issue. So it would give us a hint for evaluating other areas if we understand exactly how you experienced the degradation.
There was a problem hiding this comment.
In what ways to you use auth? Just oauth web or GitHub personal access tokens, too?
I use auth to sign in to jenkins with GH credentials, I believe that's all:
Here is my oath configuration (config-as-code)
jenkins:
securityRealm:
github:
clientID: "XXX"
clientSecret: "XXX"
githubApiUri: "https://api.github.com"
githubWebUri: "https://github.com"
oauthScopes: "read:org,user:email,repo"
How are your jobs organized? Are they in folders or grouped into views?
There are less than 10 jobs. No folders
Where were performance issues most noticeable?
Running any declarative pipeline. It's slow as molasses
How many users?
Just me
Also if you could describe how you evaluated the 20x
Pipelines that used to take 1 minute now take 15 minutes :)
Thanks for your help
|
I created a JIRA issue: https://issues.jenkins.io/browse/JENKINS-72276 |
Should resolves JENKINS-72268 and potentially JENKINS-72209.
The
ghvariable is set for a token only when the cache does not contain the username (code). But, if you are using impersonation, like in situations explained in the ticket, the cache will contain the token and thus, me != null, leading to a token with gh=null.Due to this, the authorities are not loaded because the gh is null.
Testing done
I tested with and without the user in my local storage (same behavior). The impersonation did not work before and now is working as expected.
The second commit is about a cast exception being thrown when trying to request the group information without directly using the expected token. Better to return the expected exception instead. Tested before and after, the behavior is "cleaner".
Due to the number of manual tests I did using breakpoints here and there to reproduce the problem and understand the source, I am not sure I can write a unit test without spending 4-5x the time.
Submitter checklist