New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[JENKINS-69488] do not SnapShot GitHubAppCredentials #616
Conversation
The GitHubApp Credentials converts itself when serialized over remoting to a DelegatingGitHubAppCredentials to support token refresh. Whilst it would naively be trivial to replace this with an implenentation in the GitHubAppCredentialsSnapshotTaker that did the conversion, this causes issues in controller to controller propagation. When a Snapshot is taken there may or may not be a Channel in place, however this does not detract from the fact that it is done so credentials can be held complete The code could be obtaining the credentials to send to some code but may be doing it in outside of a specific task (th a remoting channel (e.g. snapshot a credential, then obtain a channel from a computer to execute some code). Whilst unlikely for this specific credential type - it is also a very generic type and nothing would prevent code from doing this - nor would that code be incorrect.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems safe enough for a hotfix, though I recommend removing the writeReplace
so that only CredentialsProvider.snapshot
(typically called from git-client
IIRC) will activate the special behavior.
I think this is the same flaky test @olamy was trying to track down in https://github.com/jenkinsci/github-branch-source-plugin/pull/609/checks?check_run_id=7918023888 ? |
possibly not flaky - failed twice locally, reset to master and it passed twice in a row... |
Selectivly reverts part of 609
"Generating App Installation Token for app ID 54321", // 1 | ||
"Generating App Installation Token for app ID 54321", // 2 | ||
"Failed to generate new GitHub App Installation Token for app ID 54321: cached token is stale but has not expired", // 3 | ||
"Generating App Installation Token for app ID 54321 on agent", // 1 | ||
"Failed to generate new GitHub App Installation Token for app ID 54321 on agent: cached token is stale but has not expired", // 2 | ||
"Generating App Installation Token for app ID 54321 on agent", // 3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this happening? The tokens are supposed to be generated on the controller, not the agent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the logs are logs of both the agent and the controller - so the token should be "generated" on the agent (but it is not generated there - it is just asking the controller).
Line 583 in 7618247
Level.FINE, "Generating App Installation Token for app ID {0} on agent", appID); |
The order here is messed up - the logs are "all the agent logs" then "all the controller logs". that really confused me at first and I am fixing that now so the logs will always be in the correct order. (which is why I have not yet enabled auto merge)
#609 fixed the test (but left the bug) - because the Delegated
credential was no longer sent to the agent (as it was Snapshotted and converted to a basic username password) and so it never refreshed on the agent as it never existed there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should be a bit more cleaner now in 751a870
I have run the test locally with both java8 and java11 (windows) where it had appeared to be flaky previously. it did not fail locally for me. There is now more logging should it become flaky or the CI fails. |
WorkflowRun run = job.scheduleBuild2(0).waitForStart(); | ||
r.waitUntilNoActivity(); | ||
|
||
System.out.println(JenkinsRule.getLog(run)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
replaced by the BuildWatcher.
// but even though we can not capture the logs we want to echo them | ||
r.showAgentLogs(agent, loggerRule); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could probably rework showAgentLogs
to mirror messages to the controller with a prefix or whatever.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure I understand.
Do you mean set a formatter here that prepends "$agentName"?
In which case something for JTH outside of the scope here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
something for JTH
Right.
outside of the scope here
Well, except insofar as it would be handy to pick up here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the logs already contain the agent name., slave0
in the below example
61.145 [test-creds #1] using credential myAppCredentialsId
61.145 [test-creds #1] Fetching changes from the remote Git repository
61.206 [slave0] [id=211] FINE o.j.p.g.GitHubAppCredentials$DelegatingGitHubAppCredentials#getPassword: Generating App Installation Token for app ID 54321 on agent
61.207 [id=102] FINE o.j.p.g.GitHubAppCredentials$DelegatingGitHubAppCredentials$GetToken#call: Generating App Installation Token for app ID 54321 for agent
61.403 [test-creds #1] Checking out Revision a9cd113a37fe363bc18dc40ac3bb1024bbc62842 (refs/remotes/origin/master)
61.558 [test-creds #1] Commit message: "init"
61.578 [id=181] FINE o.j.p.g.GitHubAppCredentials#getToken: Generating App Installation Token for app ID 54321
So I'm no longer clear what is being asked here @jglick
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
perhaps it is the comment that is missleading. it is in reference to the comment on the LoggerRule
Lines 98 to 102 in a45d053
// here to aid debugging - we can not use LoggerRule for the test assertion as it only captures | |
// logs from the controller | |
@ClassRule | |
public static LoggerRule loggerRule = | |
new LoggerRule().record(GitHubAppCredentials.class, Level.FINE); |
long notStaleSeconds = GitHubAppCredentials.AppInstallationToken.NOT_STALE_MINIMUM_SECONDS; | ||
final long notStaleSeconds = | ||
GitHubAppCredentials.AppInstallationToken.NOT_STALE_MINIMUM_SECONDS; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No-op?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Used in the finally block which is untouched so not in the diff.
Lines 397 to 400 in f961f1d
} finally { | |
GitHubAppCredentials.AppInstallationToken.NOT_STALE_MINIMUM_SECONDS = notStaleSeconds; | |
logRecorder.doClear(); | |
} |
Made it final to avoid it being changed accidentally..
Probably should use a FlagRule but probably best left for a larger cleanup
long notStaleSeconds = GitHubAppCredentials.AppInstallationToken.NOT_STALE_MINIMUM_SECONDS; | ||
final long notStaleSeconds = | ||
GitHubAppCredentials.AppInstallationToken.NOT_STALE_MINIMUM_SECONDS; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto
// (agent log added out of order, see below) | ||
"Generating App Installation Token for app ID 54321", // 1 | ||
"Generating App Installation Token for app ID 54321", // 2 | ||
"Failed to generate new GitHub App Installation Token for app ID 54321: cached token is stale but has not expired", // 3 | ||
// node ('my-agent') { | ||
// checkout scm | ||
// checkout scm | ||
// echo 'First Checkout on agent should use cached token passed via remoting' | ||
// git url: REPO, credentialsId: 'myAppCredentialsId' | ||
"Generating App Installation Token for app ID 54321", | ||
// echo 'Multiple checkouts in quick succession should use cached token' | ||
// git .... | ||
// (No token generation) | ||
// sleep | ||
// echo 'Checkout after token is stale refreshes via remoting - fallback due to | ||
// unexpired token' | ||
// git .... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a diff link to the pre-#609 state for ease of review?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. I guess the non-obvious parts of the test diff are due to the addition of chronological sorting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yup. those where already commented inline (but the message may have changed slightly
src/test/java/org/jenkinsci/plugins/github_branch_source/GithubAppCredentialsTest.java
Outdated
Show resolved
Hide resolved
…bAppCredentialsTest.java Co-authored-by: Jesse Glick <jglick@cloudbees.com>
Fine for me; let me know if and when you want this merged & released. |
The GitHubApp Credentials converts itself when serialized over remoting
to a DelegatingGitHubAppCredentials to support token refresh.
Whilst it would naively be trivial to replace this with an
implenentation in the GitHubAppCredentialsSnapshotTaker that did the
conversion, this causes issues in controller to controller propagation.
When a Snapshot is taken there may or may not be a Channel in place,
however this does not detract from the fact that it is done so
credentials can be held complete
The code could be obtaining the credentials to send to some code but may
be doing it in outside of a specific task (th a remoting channel (e.g. snapshot a credential, then
obtain a channel from a computer to execute some code). Whilst unlikely
for this specific credential type - it is also a very generic type and
nothing would prevent code from doing this - nor would that code be
incorrect.
This change purely goes back to the status quo before jenkinsci/credentials-plugin#327 was introduced.
Description
A brief summary describing the changes in this pull request. See
JENKINS-69488 for further information.
required due to jenkinsci/credentials-plugin#327 see also #336 #334
Submitter checklist
Reviewer checklist
Documentation changes
Users/aliases to notify