Skip to content
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

not using available resolvers #108

Closed
BusyByte opened this issue Jul 8, 2020 · 21 comments · Fixed by #278
Closed

not using available resolvers #108

BusyByte opened this issue Jul 8, 2020 · 21 comments · Fixed by #278

Comments

@BusyByte
Copy link

BusyByte commented Jul 8, 2020

Plugin version addSbtPlugin("org.scalameta" % "sbt-scalafmt" % "2.4.0")

When running scalafmtAll command:

[error] (my-application / Compile / scalafmt) failed to resolve Scalafmt version '2.6.2': https://artifactory.my-company-artifactory.com/artifactory/libs-release/com/googlecode/java-diff-utils/diffutils/1.3.0/diffutils-1.3.0.jar: unauthorized: https://artifactory.my-company-artifactory.com/artifactory/libs-release/com/googlecode/java-diff-utils/diffutils/1.3.0/diffutils-1.3.0.jar (Artifactory Realm)
  [error] https://artifactory.my-company-artifactory.com/artifactory/libs-release/org/scalameta/fastparse-utils_2.13/1.0.1/fastparse-utils_2.13-1.0.1.jar: unauthorized: https://artifactory.my-company-artifactory.com/artifactory/libs-release/org/scalameta/fastparse-utils_2.13/1.0.1/fastparse-utils_2.13-1.0.1.jar (Artifactory Realm)
  [error] https://artifactory.my-company-artifactory.com/artifactory/libs-release/org/scalameta/fastparse_2.13/1.0.1/fastparse_2.13-1.0.1.jar: unauthorized: https://artifactory.my-company-artifactory.com/artifactory/libs-release/org/scalameta/fastparse_2.13/1.0.1/fastparse_2.13-1.0.1.jar (Artifactory Realm)

Note: the above has been anonymized.

I talked to our infra team and they say that the scalafmt plugin is not using the available resolvers/creds so it's getting unauthorized and is the only plugin having this issue.

@poslegm
Copy link
Collaborator

poslegm commented Jul 8, 2020

Hello! How resolvers are specified in the build.sbt?

@BusyByte
Copy link
Author

BusyByte commented Jul 8, 2020

@poslegm

for the build.sbt it is:

val myCompanyReleases ="MyCompany Artifactory Releases" at "https://artifactory.my-company-artifactory.com/artifactory/libs-release"

 val myCompanyRepositorySettings: Seq[Setting[_]] = Seq(
    resolvers := Seq(myCompanyReleases),
    externalResolvers ++= resolvers.value
  )

@BusyByte
Copy link
Author

BusyByte commented Jul 8, 2020

@poslegm then in the plugins.sbt it is:

resolvers += "My Company Artifactory Lib Releases".at(
  "https://artifactory.my-company-artifactory.com/artifactory/libs-release"
)

@poslegm
Copy link
Collaborator

poslegm commented Jul 8, 2020

Related issue: scalameta/scalafmt#1521 (comments may be helpful)

What version of sbt do you use?

@BusyByte
Copy link
Author

BusyByte commented Jul 8, 2020

@poslegm from build.properties it is sbt.version=1.3.13

@poslegm
Copy link
Collaborator

poslegm commented Jul 8, 2020

And how do you pass credentials to sbt?

@BusyByte
Copy link
Author

BusyByte commented Jul 8, 2020

@poslegm
we set them in ~/.ivy2/.credentials
and we add credentials += Credentials(Path.userHome / ".ivy2" / ".credentials") to ~/.sbt/1.0/global.sbt

@BusyByte
Copy link
Author

BusyByte commented Jul 8, 2020

@poslegm we also set an environment variable:
SBT_CREDENTIALS="$HOME/.ivy2/.credentials"

@poslegm
Copy link
Collaborator

poslegm commented Jul 9, 2020

As I understand here @ceedubs also faced a credentials problem. @ceedubs may be you can help with it?

@BusyByte now I can only advise you to try moving credentials += ... to project's build.sbt from ~/.sbt/1.0/global.sbt, but I am not sure that it will help :(

@ceedubs
Copy link

ceedubs commented Jul 9, 2020

@BusyByte I'm not sure that I can shed any light on what's going wrong for you, but I can tell you the setup that we have that is working for us with our Artifactory server. I'm not sure that it should be necessary to set these values, but it works so I'm not touching it 😛. We are configuring the SBT repositories and credentials in a somewhat normal way but then we are also setting the following environment variables.

  • Set the COURSIER_CREDENTIALS env var to point to a Coursier credentials file
    • It's kind of buried in the docs but make sure that it starts with / or file: if you are pointing to a file and not hard-coding the credentials.
  • Set the COURSIER_REPOSITORIES env var
    • Example: ivy2Local|https://repo.yourbusiness.com/artifactory/libs-release/|ivy:https://repo.yourbusiness.com/artifactory/bintray_sbt/[organization]/[module]/(scala_[scalaVersion]/)(sbt_[sbtVersion]/)[revision]/[type]s/[artifact](-[classifier]).[ext]

@BusyByte
Copy link
Author

BusyByte commented Jul 9, 2020

@ceedubs ok I'll review this and give it a shot and see if it resolves the issue. It may be a bit before I get back to you but I'll report back my results.

@BusyByte
Copy link
Author

@ceedubs adding COURSIER_CREDENTIALS and COURSIER_REPOSITORIES did not help. still seeing the unauthorized downloading the artifacts from artifactory.
We did find a work around is to add maven-central to our repositories file which causes it to bypass artifactory. Not ideal as it has downsides but it works.

@lvauthrin
Copy link

I'm not sure if I ran into the same issue or not, but I was having trouble resolving artifacts via Artifactory when scalafmt was running. I created a credentials file and set the COURSIER_CREDENTIALS env var to point to it and that seemed to fix my issue. Perhaps there's a place where the credentials still need to be linked?

Sbt version: 1.4.4
Scalafmt version: 2.4.2
Sbt-scalafmt version: 2.3.4

@pshemass
Copy link

pshemass commented Feb 24, 2021

@BusyByte I spent two days debugging this and I figured out that to work with our Artifactory setup I had to add pass-on-redirect and auto properties.

create credentials.properties in home directory

simple.realm=Artifactory Realm
simple.host=artifactory.foo.bar.com
simple.username=john.doe
simple.password=secret
simple.pass-on-redirect=true
simple.auto=true

then you should be able to

export COURSIER_CREDENTIALS=$HOME/credential.properties
sbt scalafmt

if you are on Windows remember that you still need to provide / at the beginning of the path
SET COURSIER_CREDENTIALS=/D:/Users/me.myself/credentials.properties

@daddykotex
Copy link

This is an old issue but I'll post my findings anyway.

  • sbt-scalafmt: 2.4.5
  • io.coursier.interfaces: 0.0.17 (embeded coursier: v2.0.0-RC5-6)
  • sbt: 1.5.5

At work, we have a very constrained setup:

  • we only have access to our internal repository (that's not entirely true, but for the purpose of this issue, it is)
  • so our setup include sbt.override.build.repos=true and a strict list of repositories in ~/.sbt/repositories
  • our sbt credentials are written to a file in ~/.sbt/.credentials and are loaded via ~/.sbt/1.0/credentials.sbt

In our setup, the problem happens because sbt-scalafmt uses coursier via io.get-coursier:interface. scalafmt will call Fetch to retrieve the dependencies. To do so, it grabs the repositories from sbt fullResolvers settings and pass them to the Fetch call. But it only passes the root (i.e.: http://your.artifactory.com/some-repo) url, not the credentials that could be associated to it. It is implied that, since we're using coursier, we'll deal with credentials the coursier way. And that means one of two things at the moment

  1. you use the ENV var COURSIER_CREDENTIALS (pointing to a file, or embedding credentials directly)
  2. you use that Java system properties -Dcoursier.credentials

We used 1) and we pointed it to a file. At first, I tried pointing it to our ~/.sbt/.credentials file, because I figured, they are the same ( THEY ARE NOT, I wasted so much time on this lol). Eventually, I realized the following:

  1. coursier needs the prefix, in the credentials file, prefix.username not username
  2. coursier uses username not user like sbt or ivy
  3. our particular setup required prefix.auto=true as @pshemass suggested (thanks)

So eventually, we ended up with a second file: ~/.sbt/.credentials-coursier which is a slight modification of ~/.sbt/.credentials (added prefix, username instead of user and prefix.auto=true). We exported the location of the file via the COURSIER_CREDENTIALS env var, and it worked.

@daddykotex
Copy link

I have some suggestion on how to improve the situation:

  1. support for the same properties format as sbt/via (maybe via a fallback) in coursier cc @alexarchambault
  2. passing sbt allCredentials (that matches the repositories in fullResolvers to coursier)

@lukestephenson-zendesk
Copy link

I've just started seeing what could be very similar issue to this with scalafmt. We also resolve dependencies via -Dsbt.override.build.repos=true and -Dsbt.repository.config.

This appears to break scalafmt:

➜  my project >> SBT_OPTS='' sbt scalafmt
[info] welcome to sbt 1.8.3 (Homebrew Java 20.0.1)
[info] loading settings for project global-plugins from credentials.sbt ...
[info] loading global plugins from /Users/lstephenson/.sbt/1.0/plugins
[info] loading settings for project escape-build from plugins.sbt ...
[info] loading project definition from /Users/lstephenson/Code/zendesk/escape/project
[info] loading settings for project root from build.sbt ...
[info] set current project to escape (in build file:/Users/lstephenson/Code/zendesk/escape/)
[success] Total time: 1 s, completed 18 May 2023, 3:39:00 pm
➜  my project >>  SBT_OPTS='-Dsbt.override.build.repos=true -Dsbt.repository.config=/Users/lstephenson/.zdi/artifactory/sbtrepos' sbt scalafmt
[info] welcome to sbt 1.8.3 (Homebrew Java 20.0.1)
[info] loading settings for project global-plugins from credentials.sbt ...
[info] loading global plugins from /Users/lstephenson/.sbt/1.0/plugins
[info] loading settings for project escape-build from plugins.sbt ...
[info] loading project definition from /Users/lstephenson/Code/zendesk/escape/project
[info] loading settings for project root from build.sbt ...
[info] set current project to escape (in build file:/Users/lstephenson/Code/zendesk/escape/)
[error] org.scalafmt.sbt.ScalafmtSbtReporter$ScalafmtSbtError: scalafmt: [v3.7.3] failed to download [/Users/lstephenson/Code/zendesk/escape/.scalafmt.conf]
[error] (Compile / scalafmt) org.scalafmt.sbt.ScalafmtSbtReporter$ScalafmtSbtError: scalafmt: [v3.7.3] failed to download [/Users/lstephenson/Code/zendesk/escape/.scalafmt.conf]
[error] Total time: 3 s, completed 18 May 2023, 3:39:34 pm

The error message is very obscure, but definitely correlates with the use of -Dsbt.repository.config.

And completely unexplained, this appears to affect my M1 macbook, but not my older intel chip.

@jaecktec
Copy link

Hey so thanks to @daddykotex I was able to get everything working, but TBO I wasted 1 Day on this. Finding this on google is not super straightforward - If this issue doesn't get fixed, can we at least document it on the official page? :)

@kitbellew
Copy link
Contributor

Hey so thanks to @daddykotex I was able to get everything working, but TBO I wasted 1 Day on this. Finding this on google is not super straightforward - If this issue doesn't get fixed, can we at least document it on the official page? :)

@jaectec @daddykotex would you be willing to contribute a step-by-step process to achieve this? I'm a complete dummy both in sbt and coursier.

the file to modify is docs/installation.md under the scalafmt repo, there's a section on sbt.

@jaecktec
Copy link

jaecktec commented Aug 21, 2023

I think #108 (comment) has already summed up perfectly. create that file and expose it through the environment variable

But I think that this issue is probably better addressed in https://github.com/scalameta/scalafmt since it contains the downloader code - and maybe there is already something related: scalameta/scalafmt#3316?

@kitbellew
Copy link
Contributor

Documentation was added in scalameta/scalafmt#3621.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants