Fix intermittent auth failure to artifactory from Jenkins #9658
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Reported the bug to SBT: sbt/sbt#6533 |
In 41e376a, the build was updated to support publishing from Travis CI. However, on Jenkins, the old means of supplying the publish credentials to pr-validation snapshots was retained, it has a ~/.credentials file. So we provided two credentials for the same host/realm to SBT, and on Jenkins the DirectCredentials contains an empty password. Which one of these would SBT pick? ``` sbt 'setupPublishCore https://scala-ci.typesafe.com/artifactory/scala-pr-validation-snapshots/' 'show credentials' [info] compiler / credentials [info] List(DirectCredentials("Artifactory Realm", "scala-ci.typesafe.com", "scala-ci", ****), FileCredentials("/Users/jz/.credentials")) [info] scalap / credentials ... <10 more like this> [info] credentials [info] List(DirectCredentials("Artifactory Realm", "scala-ci.typesafe.com", "scala-ci", ****)) ``` The `ivySbt` task in SBT registers the credentials in order in a global map in Ivy (`CredentialStore`). So on Jenkins, the invalid `DirectCredentials` would be overwritten in the map by he `FileCredentials`. But the fact that this is global state in Ivy appears to be a source of cross talk between the configured credentials for different modules in the build. Even though the publish task is serialized through the ivy lock, this lock does not enclose the previous execution of the `ivySbt` which sets up the credentials in `CredentialStore`. In our build, notice that the root project does _not_ have the `FileCredentials` set. So if the `ivySBT` task for this project runs last, the global map will have the incorrect `DirectCredentials`. The fix in our build is easy, avoid configuring the `DirectCredentials` if the environment variables are absent. We can also standardize on using `Global/credentials := `. The principled fix in SBT would be to thread the credentials down to the HTTP client without using global state. It could also emit a warning if conflicting credentials are configured for a given host/realm.
170dfee to
a8ec10d
Compare
dwijnand
approved these changes
Jun 7, 2021
21 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In 41e376a, the build was updated to support publishing from
Travis CI.
However, on Jenkins, the old means of supplying the publish
credentials to pr-validation snapshots was retained, it has
a ~/.credentials file. So we provided two credentials for the
same host/realm to SBT, and on Jenkins the DirectCredentials
contains an empty password.
Which one of these would SBT pick?
The
ivySbttask in SBT registers the credentials in order in a global mapin Ivy (
CredentialStore). So on Jenkins, the invalidDirectCredentialswould be overwritten in the map by he
FileCredentials.But the fact that this is global state in Ivy appears to be a source of cross
talk between the configured credentials for different modules in the build.
Even though the publish task is serialized through the ivy lock, this lock
does not enclose the previous execution of the
ivySbtwhich sets up thecredentials in
CredentialStore.In our build, notice that the root project does not have the
FileCredentialsset. So if theivySBTtask for this project runs last,the global map will have the incorrect
DirectCredentials.The fix in our build is easy, avoid configuring the
DirectCredentialsif theenvironment variables are absent. We can also standardize on using
Global/credentials :=.The principled fix in SBT would be to thread the credentials down to the HTTP
client without using global state. It could also emit a warning if conflicting
credentials are configured for a given host/realm.