-
Notifications
You must be signed in to change notification settings - Fork 126
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
Use short-lived tokens instead of Access key #426
Conversation
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.
Nice! 🎉
src/main/java/hudson/plugins/gradle/injection/BuildScanEnvironmentContributor.java
Outdated
Show resolved
Hide resolved
DevelocityLogger logger = new DevelocityLogger(listener); | ||
if (secretKey != null && DevelocityAccessKey.isValid(secretKey.getPlainText())) { | ||
shortLivedToken = tokenClient.get(InjectionConfig.get().getServer(), | ||
DevelocityAccessKey.parse(secretKey.getPlainText()), |
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.
Unless I'm mistaken, this parse
method assumes that the access key contains a single server=key
entry, but the isValid
method above will pass for a key with server1=key1;server2=key2
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.
You're right, then we need to extract the hostname from the DV server URL and try to find the corresponding key
tokenClient.get(serverUrl, k, InjectionConfig.get().getShortLivedTokenExpiry())) | ||
.filter(Optional::isPresent) | ||
.map(k -> Secret.fromString(k.get().getRawAccessKey())) | ||
.orElse(null); |
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.
If we fail to get a short-lived access token, do we want to fail the build, or fall back to some reasonable behavior?
In our own dogfooding case, we decided to not set the access key and let the build fail to use various Develocity features like build caching and build scan publishing. However, we had to explicitly disable Test Distribution (which will otherwise fail if it fails to connect to Develocity). I wonder if we should do something similar here.
I also wonder if it would make sense to add a configuration option to allow users to decide if they want the build to fail if it can't get an access token, or to continue without Develocity.
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.
I would not fail the build as the injection applies to potentially hundreds/thousands of projects. We can check later if we want to introduce a configuration option to do that (and research if it's even possible to fail the build from this hook).
For now the behavior is the same as you described, except we did not implement any specific behavior for Test Distribution since we do not configure it with the injection (nor build cache btw).
url = url + "?expiresInHours=" + expiry; | ||
} | ||
|
||
Request request = new Request.Builder() |
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.
I recommend implementing some form of a retry mechanism. That way, if the Develocity instance is down briefly, the build has a chance of still working.
We found a retry mechanism to be quite helpful in our own dogfooding of short-lived access tokens.
Nice fix! JENKINS-73082 would also be nice to fix. |
Generate a short lived token before each build and use it in the env var instead of the access key.
A new UI parameter is introduced to control the tokens expiry:
Testing done
Submitter checklist