## Bug Description `glab artifact-registry login --sbt` writes its credential to `~/.sbt/1.0/credentials.sbt`, which is sbt **1.x**'s global base. A project running sbt **2.x** does not load global `.sbt` files from there, so the token lands where no build reads it and the next resolve fails `unauthorized`. The command reports success either way. ## Steps to Reproduce 1. Have a Maven artifact in a `hosted` Maven repository, and set: ```shell AR_HOST=staging.artifact-registry-gke.svc.gitlab.net SLUG=<your slug> REG="https://$AR_HOST/$SLUG/maven/<repo>" ``` 2. Log in. This reports success and writes the file: ```shell glab artifact-registry login --sbt --registry "$REG" \ --hostname staging.gitlab.com --duration 2h ls -l ~/.sbt/1.0/credentials.sbt # present, mode 0600 ``` 3. Create a consumer that resolves that artifact: ```shell mkdir -p /tmp/sbt-probe/project && cd /tmp/sbt-probe cat > build.sbt <<EOF ThisBuild / scalaVersion := "3.3.4" lazy val root = (project in file(".")) .settings( resolvers += ("ar" at "$REG"), libraryDependencies += "<group>" % "<artifact>" % "<version>", ) EOF ``` 4. Pin sbt 2.x. The launcher runs whatever the project declares, so one machine covers both versions: ```shell echo 'sbt.version=2.0.8' > project/build.properties rm -rf ~/Library/Caches/Coursier/v1/https/$AR_HOST # or a cache hit hides it sbt -batch update # fails ``` 5. Repeat with `sbt.version=1.10.7` and the cache cleared again. It succeeds. Reproducibility: always Reproduced independently: yes, on staging 2026-09-02 ## Expected Behavior After `login --sbt` reports success, an sbt build resolving from that registry authenticates. `--help` does state that `--sbt` "assumes a stock sbt 1.x" and that an sbt with "a newer default" global base "does not read that file", so the behaviour is documented; what is not acceptable is that the caveat lives only in `--help` while the success line prints unconditionally. ## Actual Behavior sbt 2.0.8: ``` [info] welcome to sbt 2.0.8 (Homebrew Java 17.0.16) [error] unauthorized: https://staging.artifact-registry-gke.svc.gitlab.net/ar-registry/maven/ conformance-maven/com/gitlab/conformance/ar-staging-probe/1.0.0/ar-staging-probe-1.0.0.pom (artifact-registry) ``` sbt 1.10.7, same credential file, cache cleared: ``` [info] welcome to sbt 1.10.7 (Homebrew Java 17.0.16) [success] Total time: 4 s ``` `unauthorized ... (artifact-registry)` means the resolver reached the right host and matched the realm the file declares, so the credential is **missing**, not rejected. Artifact Registry answered correctly. Where the credential is read from, measured with the identical line moved between locations, sbt 2.0.8 each time, cache cleared each time: | Location | sbt 1.10.7 | sbt 2.0.8 | |---|---|---| | `~/.sbt/1.0/credentials.sbt` (what `glab` writes) | resolves | `unauthorized` | | `~/.sbt/2.0/credentials.sbt` | not tested | `unauthorized` | | `~/.sbt/credentials.sbt` | not tested | `unauthorized` | | `~/.sbt/1.0/global.sbt` | not tested | `unauthorized` | | `~/.config/coursier/credentials.properties` (± realm) | not tested | `unauthorized` | | `<project>/credentials.sbt` | not tested | **resolves** | The last row is the useful one: the realm, the `__token__` username, and the `credentials +=` syntax `glab` writes are all correct for sbt 2, which accepts that exact line when it is in scope. Only the location is wrong. ## Suggested Fix **This section is a hypothesis, not a finding.** `internal/commands/artifactregistry/login/sbt.go:102-113` explains why the base is not detectable from outside a build: the override is a JVM property passed on the sbt command line or through `SBT_OPTS`, and the binary version belongs to whichever sbt the build runs. That reasoning holds, so detection is the wrong thing to attempt. In rough order of cost: 1. Carry the caveat on the success path, naming the path written and the sbt version it applies to. Cheapest, and worth doing regardless of the rest. 2. Add an override so a user on a non-1.x base can redirect the write, for example `--sbt-credentials-path` or honouring `SBT_GLOBAL_BASE`. This sidesteps detection entirely. 3. Write sbt 2.x's global location too, once the table above has a positive row for one. An unread file in the other base is inert, so writing both is safe. 4. If sbt 2.x has no suitable global location, say so in `--help` and point users at a project-local `credentials.sbt`, which is verified to work. ## Suggested DRI `glab ar login` client auth ([#222](https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/222)), DRI @sylviashen. That surface owns the per-tool credential writers, and the fix is in one of them; the Maven format workstream owns the registry side, which is behaving correctly here. Unassigned, per triage policy. ## Labels to Apply - `type::bug` - `severity::3` — a real workaround exists and was tested: a project-local `credentials.sbt` resolves on sbt 2.x, as does pinning `sbt.version` to 1.x. Not `severity::2`, because nothing is broken without a workaround and the affected population is projects already on sbt 2.x rather than everyone. Not `severity::4`, because the target is entirely ineffective for those projects rather than merely inconvenient. - `Category:Artifact Registry` - `artifact-registry::cli` - `backend` - `format::maven`, `repo-type::hosted` - `bug::functional` - No `AR-Blocks::*`: at `severity::3` the epic's guide asks for one only when a specific gate is genuinely blocked, and no CB, GA, SM or Dedicated gate depends on sbt 2.x support. ## Additional Context | | | |---|---| | Environment | staging | | Org slug | `ar-registry` | | Repository | `conformance-maven`, hosted | | Format | Maven (via sbt) | | Auth method | token exchange, `glab artifact-registry get-token` | | Client and version | `sbt 2.0.8` and `sbt 1.10.7`, Homebrew Java 17.0.16, `glab 1.116.0` at `b05b9ae2` | | First observed (UTC) | 2026-09-02 15:16 | | Correlation ID | _None — the failure is client-side; Artifact Registry returned a correct 401._ | | Workaround | A project-local `credentials.sbt`, or pin `sbt.version` to 1.x. Both tried and both work. | `brew install sbt` installs 2.0.8 as of 2026-09-02, but that alone does not decide who is affected: the launcher runs whatever `project/build.properties` declares, and the global base follows that version rather than the installed binary. A machine with 2.0.8 installed resolves fine against a project pinned to 1.x. So the affected set is projects that have moved to sbt 2.x. Two ways to get a false result while verifying, both hit here: - A `cp.files` fixture does not compile under sbt 2, which removed it in favour of an `xsbti.FileConverter`. The build then fails on syntax before resolution and says nothing about credentials. Use `update` instead. - Not clearing the coursier cache lets the second run pass without authenticating. Related: [#1039](https://gitlab.com/gitlab-org/ops/artifact-registry/-/work_items/1039) covers sbt being absent from the UI setup snippets. Distinct defect, same client. That issue states `glab artifact-registry login` "already produce[s] correct configuration for all four clients", which this qualifies: correct for sbt 1.x, written where sbt 2.x does not read it.