guettli/sharedinbox
1
0
Fork 0
Code Issues 21 Pull Requests 6 Actions Packages Projects Releases Wiki Activity

How to avoid version mismatch in the future? #396

New Issue
Closed
opened 2026-06-04 01:00:20 +00:00 by guettli · 2 comments
guettli commented 2026-06-04 01:00:20 +00:00 (Migrated from codeberg.org)
Copy Link
Copy Source

How to avoid version mismatch in the future?

Look at https://codeberg.org/guettli/sharedinbox/issues/394

Create plan

How to avoid version mismatch in the future? Look at https://codeberg.org/guettli/sharedinbox/issues/394 Create plan
guettlibot commented 2026-06-04 01:10:02 +00:00 (Migrated from codeberg.org)
Copy Link
Copy Source

Now I have enough context. Let me write the implementation plan.

Implementation Plan: Eliminate Flutter version mismatch between .fvmrc and ci/main.go

Root cause

Two independent strings encode the Flutter version:

  1. .fvmrc — the canonical FVM pin, used locally ({ "flutter": "3.44.1" })
  2. ci/main.go line 184 — the Dagger toolchain container tag, hardcoded as ghcr.io/cirruslabs/flutter:3.44.0

Also, the Graph() diagram at line 905 still shows flutter:3.41.6 as a stale label — a third diverging value.

Solution: single source of truth

Make ci/main.go read .fvmrc at Dagger module initialization time and derive the image tag from it. The string exists once; they cannot drift.

Changes — ci/main.go only (no schema, no build_runner)

1. Add .fvmrc to the source filter in New()

Add ".fvmrc" to the Include slice so the file is available inside the Dagger module.

2. Change New() to read and parse .fvmrc

Update the signature to func New(ctx context.Context, source *dagger.Directory) (*Ci, error). In the body:

  • Call source.File(".fvmrc").Contents(ctx) to get the raw JSON.
  • Unmarshal the flutter field (e.g. "3.44.1") into a local variable.
  • Store it on the struct: add FlutterVersion string to type Ci struct.
  • Return an error if .fvmrc is missing or unparseable, with a clear message.

3. Update toolchain() to use m.FlutterVersion

Replace the hardcoded "ghcr.io/cirruslabs/flutter:3.44.0" with:

"ghcr.io/cirruslabs/flutter:" + m.FlutterVersion

4. Fix the stale label in Graph()

The diagram comment at line 905 says flutter:3.41.6. Replace it with a %s format so Graph() returns:

fmt.Sprintf(`...toolchain\nflutter:%s + NDK + apt + precache...`, m.FlutterVersion)

What this does NOT change

  • No Taskfile changes needed.
  • No CI YAML changes needed.
  • No Renovate rules needed.
  • No pre-commit hooks needed.
  • The workflow for bumping Flutter remains: edit .fvmrc (via Renovate or manually) — CI and local builds both pick up the new version automatically on next run.
Now I have enough context. Let me write the implementation plan. --- ## Implementation Plan: Eliminate Flutter version mismatch between `.fvmrc` and `ci/main.go` ### Root cause Two independent strings encode the Flutter version: 1. `.fvmrc` — the canonical FVM pin, used locally (`{ "flutter": "3.44.1" }`) 2. `ci/main.go` line 184 — the Dagger toolchain container tag, hardcoded as `ghcr.io/cirruslabs/flutter:3.44.0` Also, the `Graph()` diagram at line 905 still shows `flutter:3.41.6` as a stale label — a third diverging value. ### Solution: single source of truth Make `ci/main.go` read `.fvmrc` at Dagger module initialization time and derive the image tag from it. The string exists once; they cannot drift. ### Changes — `ci/main.go` only (no schema, no build_runner) **1. Add `.fvmrc` to the source filter in `New()`** Add `".fvmrc"` to the `Include` slice so the file is available inside the Dagger module. **2. Change `New()` to read and parse `.fvmrc`** Update the signature to `func New(ctx context.Context, source *dagger.Directory) (*Ci, error)`. In the body: - Call `source.File(".fvmrc").Contents(ctx)` to get the raw JSON. - Unmarshal the `flutter` field (e.g. `"3.44.1"`) into a local variable. - Store it on the struct: add `FlutterVersion string` to `type Ci struct`. - Return an error if `.fvmrc` is missing or unparseable, with a clear message. **3. Update `toolchain()` to use `m.FlutterVersion`** Replace the hardcoded `"ghcr.io/cirruslabs/flutter:3.44.0"` with: ```go "ghcr.io/cirruslabs/flutter:" + m.FlutterVersion ``` **4. Fix the stale label in `Graph()`** The diagram comment at line 905 says `flutter:3.41.6`. Replace it with a `%s` format so `Graph()` returns: ```go fmt.Sprintf(`...toolchain\nflutter:%s + NDK + apt + precache...`, m.FlutterVersion) ``` ### What this does NOT change - No Taskfile changes needed. - No CI YAML changes needed. - No Renovate rules needed. - No pre-commit hooks needed. - The workflow for bumping Flutter remains: edit `.fvmrc` (via Renovate or manually) — CI and local builds both pick up the new version automatically on next run.
guettlibot commented 2026-06-04 04:25:01 +00:00 (Migrated from codeberg.org)
Copy Link
Copy Source

PR is open: https://codeberg.org/guettli/sharedinbox/pulls/405

What I did

The root cause of #394 was two independent strings encoding the Flutter version: .fvmrc (the FVM pin, 3.44.1) and the hardcoded container image tag in ci/main.go (3.44.0). They drifted silently.

Fix in ci/main.go (single file, no schema changes):

  1. New() signature changed to func New(ctx context.Context, source *dagger.Directory) (*Ci, error) — it reads .fvmrc from the source directory, JSON-parses the flutter field, and fails fast with a clear error if it's missing or malformed.
  2. FlutterVersion string added to the Ci struct to carry the parsed version.
  3. .fvmrc added to the source Include filter so it's available inside the Dagger module.
  4. toolchain() now builds the image tag as "ghcr.io/cirruslabs/flutter:" + m.FlutterVersion — no more hardcoded tag.
  5. Graph() updated to use fmt.Sprintf(..., m.FlutterVersion) so the diagram label also reflects the live version rather than the previously stale 3.41.6.

From now on, bumping Flutter in .fvmrc (whether via Renovate or manually) automatically propagates to the Dagger pipeline with no separate edit needed.

PR is open: https://codeberg.org/guettli/sharedinbox/pulls/405 --- **What I did** The root cause of #394 was two independent strings encoding the Flutter version: `.fvmrc` (the FVM pin, `3.44.1`) and the hardcoded container image tag in `ci/main.go` (`3.44.0`). They drifted silently. **Fix in `ci/main.go`** (single file, no schema changes): 1. `New()` signature changed to `func New(ctx context.Context, source *dagger.Directory) (*Ci, error)` — it reads `.fvmrc` from the source directory, JSON-parses the `flutter` field, and fails fast with a clear error if it's missing or malformed. 2. `FlutterVersion string` added to the `Ci` struct to carry the parsed version. 3. `.fvmrc` added to the source `Include` filter so it's available inside the Dagger module. 4. `toolchain()` now builds the image tag as `"ghcr.io/cirruslabs/flutter:" + m.FlutterVersion` — no more hardcoded tag. 5. `Graph()` updated to use `fmt.Sprintf(..., m.FlutterVersion)` so the diagram label also reflects the live version rather than the previously stale `3.41.6`. From now on, bumping Flutter in `.fvmrc` (whether via Renovate or manually) automatically propagates to the Dagger pipeline with no separate edit needed.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
NeedSupervisor
Issue escalated to a human supervisor; agentloop will skip it until cleared.
 State/InProgress
State/Later
State/Planned
automerge
Eligible for automatic merge by CI
 ci-failure
Issue opened by agentloop to track a failing CI workflow; used for deduplication.
 do-not-merge
Plan PR — review only, do not merge.
 loop/code
Add to run the built-in "code" prompt; override at prompts/code.md.
 loop/code-ci-pending
Prompt "code" finished; waiting for the PR's CI to pass before advancing.
 loop/code-done
Prompt "code" finished successfully.
 loop/code-in-process
Agent for the "code" prompt is currently running on this issue.
 loop/merge
Managed by agentloop
 loop/merge-done
Managed by agentloop
 loop/merge-in-process
Managed by agentloop
 loop/plan
Add to run the built-in "plan" prompt; override at prompts/plan.md.
 loop/plan-done
Prompt "plan" finished successfully.
 loop/plan-in-process
Agent for the "plan" prompt is currently running on this issue.
No labels loop/code-done
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
guettlibot guettli
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: guettli/sharedinbox#396