Splitties
Private repositories fail to check
Is your feature request related to a problem? Please describe.
Both gradle sync and refreshVersions fail with 401 when using private repositories.
It would be great if they were capable of looking into them.
We have declared on the root gradle the company private repositories like usual:
allprojects {
repositories {
maven {
name = "FooBar"
url = uri("https://maven.pkg.github.com/<owner>/<repo-name>")
credentials {
username = localProperties["github.user"] as String? ?: System.getenv("GH_USER")
password = localProperties["github.access_token"] as String?
?: System.getenv("GH_ACCESS_TOKEN")
}
}
but making those dependencies with the underline _ simply crashes the sync task
Could not resolve all dependencies for configuration ':app:debugRuntimeClasspath'.
ModuleId(group=<group>, name=<artifact>) not found. Searched the following repositories:
- https://dl.google.com/dl/android/maven2/
- https://maven.pkg.github.com/<owner>/<repo-name>/
- https://repo.maven.apache.org/maven2/
- https://jcenter.bintray.com/
and when running ./gradlew refreshVersions we get 401.
<-- 401 Unauthorized https://maven.pkg.github.com/<owner>/<repo-name>/<package-name>/maven-metadata.xml (113ms, 0-byte body)
Describe the solution you'd like The tasks use the provided credentials to properly authenticate with the repos.
Describe alternatives you've considered
We're just hardcoding versions now on the buildSrc
we still get this problem (401 when trying to read maven-metadata.xml from a private artifact on jitpack) on version 0.11.0
In the main build.gradle file alongside some other repos
allprojects {
repositories {
...
maven {
url "https://jitpack.io"
credentials { username TOKEN }
}
...
}
}
Do you need anything else that might help? Accessing the dependency itself works fine, it's just the metadata file that gets a 401.
actually, it does work but then next time buildSrcLibs command overrides it back to _
is there a good solution for this?
I was asking to debug, not suggesting it as a solution. Thanks for your answer.
I suggest that you hardcode the version for these private dependencies, because investigating that issue further is not in our current priorities. I'm reopening this issue so we remember to take it into consideration.
