feat: android-flutter image + daily Claude update check #54
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "dev"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Two features stacked on
devfor review and merge:feat(images): fedora/android-flutter(60726a6) — new scc image flavor for Android + Flutter mobile dev. Fedora 44 base, Eclipse Temurin 21 LTS from tarball (Android-officially-supported), Android cmdline-tools + platform-tools + build-tools, Flutter stable precached for Android-only.linux/amd64only (Google ships no arm64 Android SDK); runs under Rosetta on Apple Silicon via OrbStack (automatic) or Docker Desktop (toggle). Auto-bump for all three new upstreams (flutter-stable,android-cmdline-tools,temurin:21) wired into the existing daily cron.feat(launcher): daily Claude Code update check(bad4785, bumpsscc.sh.version1.1.2 → 1.2.0) — scc.sh now checks once a day whether@anthropic-ai/claude-code/lateston npm is newer than what is cached in thescc-claudevolume, and prompts to reinstall. New env varsSCC_AUTO_UPDATE_CLAUDE=1(auto-update without prompting) andSCC_NO_CLAUDE_UPDATE_CHECK=1(opt out). Entrypoint mirrors the installed version to~/.scc/volume-meta/so the host can read it without a docker-exec roundtrip. Backward-compatible with old launchers (mirror silently skipped if/scc-metanot mounted).Plus a merge of
mainintodevto pick up the daily-bump activity that landed in parallel.Test plan
bash -n scc.sh && bash -n images/_common/scc-entrypoint.shcleanbats --recursive tests/→ 56/56 pass./bump-deps.sh --dry-runresolves all four new upstreams (Flutter 3.44.0, Android cmdline-tools 14742923, Temurin 21.0.11+10, plus existing bumps) with zero fetch errorsscc:android-flutter-fedora-latestsccafter merge: confirm~/.scc/volume-meta/claude_versiongets populated and contains a semver stringSCC_AUTO_UPDATE_CLAUDE=1 sccwhen remote claude is newer → no prompt, FORCE_REINSTALL kicks inUntil now scc only installed Claude once, then served the cached binary from the scc-claude volume forever — no version check, no nudge when Anthropic shipped a fix. The only refresh path was the user knowing to set SCC_FORCE_REINSTALL=1. This adds a once-per-day check mirroring the existing scc.sh self-update flow: scc.sh GETs @anthropic-ai/claude-code/latest from npm (~1 KB, 1 s timeout), compares it to the version cached in the volume, and warns + prompts when upstream is newer. Decisions are remembered per upstream version so users don't get re-prompted for the same release. Plumbing: - scc-entrypoint.sh writes `claude --version` into both /opt/scc-claude/version (canonical, lives with the binary) and /scc-meta/claude_version (bind-mounted from ~/.scc/volume-meta/, so the host launcher can read it without a docker-exec roundtrip). Re-captured after every reinstall; idempotent on the fast path. - scc.sh adds the /scc-meta mount alongside the existing volume mount. Older launchers don't mount /scc-meta; the entrypoint silently skips the mirror in that case, so a new image works with an old launcher. - New check_for_claude_update() in scc.sh: 24h-cached fetch, semver comparison via sort -V, per-version ack file at ~/.scc/claude-update-check. Fail-closed: non-TTY runs note and continue, never auto-update. Three new env vars: - SCC_AUTO_UPDATE_CLAUDE=1 skip the prompt, auto-set SCC_FORCE_REINSTALL=1 on detection. - SCC_NO_CLAUDE_UPDATE_CHECK=1 skip the daily probe entirely. - (existing SCC_FORCE_REINSTALL=1 still works; suppresses the check when set, since reinstall is already happening.) Tests: - tests/feature/helpers.bash exports SCC_NO_CLAUDE_UPDATE_CHECK=1 alongside SCC_NO_UPDATE_CHECK=1 so the daily curl never fires under test. All 56 existing bats tests pass; no new tests added (the new function is HTTP-bound and matches the established pattern). README "Claude binary handling" section gains a "Daily Claude update check" subsection documenting the prompt, the env vars, and where the metadata lives. scc.sh.version bumped 1.1.2 → 1.2.0. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>Adds a third configurable field next to image and claude_args: a docker --platform pin. Use case: running the new fedora/android-flutter image (amd64-only, since Google ships no arm64 Android SDK) on Apple Silicon under Rosetta-for-Linux. Without --platform, docker warns about arch mismatch and Rosetta's behavior is implicit; with --platform=linux/amd64 the launcher tells docker exactly what to pull + run. Resolution order matches the existing image plumbing: SCC_PLATFORM env > .scc/config.ini platform= > (omit, docker chooses) Wired through both `docker pull` and `docker run` via a shared platform_args array. The status line prints "(--platform linux/amd64)" when set so you can tell at a glance whether emulation is in play. Validation is minimal — `^[a-z0-9]+/[a-z0-9/.-]+$` catches the obvious typo (`amd64` without the `linux/` prefix) but otherwise trusts docker to error on garbage. Anything that looks like os/arch passes through. Trust gate extended: - require_project_trust() takes a 4th argument (platform). - Trust file format gains a `platform=` line. Old trust files without the line keep working because ini_get returns "" for missing keys and ""="" compares equal when the project also doesn't pin platform. Re-prompt only fires when a project NEWLY pins a platform that wasn't in the old trust file. - SCC_PLATFORM env is user-explicit and does NOT trigger the trust prompt, matching the SCC_IMAGE behavior. Tests: 3 new bats cases in project_config.bats: - platform = … in config.ini reaches docker run argv as `--platform linux/amd64` - SCC_PLATFORM env overrides the config.ini value - Malformed platform (`amd64`, no `linux/` prefix) rejected with rc=2 All 59/59 tests pass (was 56 before). README's "Schema" + "Trust prompt" sections updated to document the new field, the resolution order, and the bypass env vars. scc.sh.version bumped 1.2.0 → 1.3.0. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>