Move SDK provisioning to ~/.sdkmanrc once sdkman supports non-exact versions (sdkman-cli#1154)

[jamesdh]

Goal

Replace the hardcoded SDK version list in ansible with a ~/.sdkmanrc managed by the projects role, using non-exact ("latest" / major-pin) version specs — once SDKMAN actually supports them. Upstream is actively working on this in sdkman/sdkman-cli#1154.

Current state (what to refactor)

roles/projects/defaults/main.yml:

sdks:
  - {name: groovy, version: 4.0.15}
  - {name: gradle, version: 8.4}
  - {name: kotlin, version: 1.5.31}
  - {name: micronaut, version: 4.1.5}
  - {name: visualvm, version: 2.1.7}
  - {name: java, version: 17.0.9-tem}

roles/projects/tasks/sdk.yml loops these through sdk install {{item.name}} {{item.version}} (executed via /opt/homebrew/bin/bash since SDKMAN requires Bash 4+; see 3bd9cc1). The pins go stale — kotlin 1.5.31 is years old — and each bump is a manual edit.

Why this is blocked today (verified 2026-07-10)

.sdkmanrc only accepts exact version identifiers:

• Empirical: fresh isolated SDKMAN (script 5.20.0, self-installed same day) with .sdkmanrc containing ant=latest → sdk env install fails with ant has not been released yet / Stop! ant latest is not installed — latest is parsed as a literal version ID.
• Upstream: Question: sdkmanrc - Pin Java to minor or major-version sdkman/sdkman-cli#1154 (pin to major/minor instead of exact) is the open feature request tracking this; docs at https://sdkman.io/usage/ only show exact pins.

When #1154 ships, the refactor is

1. Add a .sdkmanrc to the projects role (e.g. roles/projects/files/.sdkmanrc) with the six candidates at latest (or major pins where preferable, e.g. java=21 if the shipped syntax supports it), symlinked to ~/.sdkmanrc alongside the role's other config.
2. Replace the Install SDKMAN sdk's loop in roles/projects/tasks/sdk.yml with a single sdk env install run in $HOME (keep executable: /opt/homebrew/bin/bash).
3. Drop the sdks var from roles/projects/defaults/main.yml — the .sdkmanrc becomes the single source of truth.
4. Keep re-run idempotency: today's guards key on is already installed / Done installing! output; re-derive equivalents from sdk env install output.

Caveats to re-check at implementation time

• Bug: sdk env install should not update global default sdkman/sdkman-cli#1457 — sdk env install currently mutates the global default candidate versions as a side effect. Confirm it's fixed (or acceptable) before switching provisioning to env install.
• sdkman_auto_env=true is already set by sdk.yml, so a ~/.sdkmanrc will be evaluated by every shell that lands in $HOME. Confirm a non-exact spec doesn't add a remote lookup (slow prompt) to shell startup on the shipped implementation.
• Note the semantics change: auto-env with a home-dir .sdkmanrc makes it the active-version authority in new shells, not just an install manifest.

Considered and deferred

Interim option (works today, not adopted): drop the version field and run bare sdk install <candidate>, which installs each candidate's current default (latest stable). Rejected for now in favor of waiting for the .sdkmanrc-native approach so the manifest lives in a file SDKMAN understands rather than in ansible vars.

Trigger

Watch sdkman/sdkman-cli#1154 (and SDKMAN release notes) — implement when the non-exact version syntax is released.