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

Renovate, and flutter version #447

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

The Flutter version (v3.44.x) gets used at several places.

All places should be in sync.

It can only upgrade if all places can get bumped.

Afaik, the docket image is not available as v3.44.1 yet.

Configure Renovate, so that version gets bumped together or not.

The Flutter version (v3.44.x) gets used at several places. All places should be in sync. It can only upgrade if all places can get bumped. Afaik, the docket image is not available as v3.44.1 yet. Configure Renovate, so that version gets bumped together or not.
guettlibot commented 2026-06-05 19:15:04 +00:00 (Migrated from codeberg.org)
Copy Link
Copy Source

I now have a full picture of the problem. Let me write the plan.

Implementation Plan for Issue #447: Renovate Flutter Version Sync

Problem

The Flutter version is declared in exactly one place — .fvmrc ({ "flutter": "3.44.0" }). The Dagger CI pipeline (ci/main.go:202) reads .fvmrc at runtime and constructs the Docker image tag ghcr.io/cirruslabs/flutter:<version> dynamically. There is no hardcoded version string to keep in sync elsewhere.

The real risk: Renovate could bump .fvmrc to a version (e.g. 3.44.1) for which ghcr.io/cirruslabs/flutter:3.44.1 does not yet exist, causing CI to fail on the image pull.

No grouped-update problem exists — there is only one file to update. The problem is purely about gating the bump on Docker image availability.

Solution: Custom Renovate Manager Backed by Docker Datasource

Add a customManager entry to renovate.json that:

  1. Reads the version string from .fvmrc.
  2. Uses ghcr.io/cirruslabs/flutter as the package with the docker datasource.
  3. Renovate will only propose a PR if the corresponding image tag actually exists in the registry — solving the availability gating problem.

Change Required

File: renovate.json — add one entry to customManagers:

{
  "customType": "regex",
  "fileMatch": ["^\\.fvmrc$"],
  "matchStrings": ["\"flutter\":\\s*\"(?<currentValue>[^\"]+)\""],
  "depNameTemplate": "ghcr.io/cirruslabs/flutter",
  "datasourceTemplate": "docker",
  "versioningTemplate": "semver"
}

This regex extracts the value of the "flutter" key from .fvmrc. Renovate will look up available tags for ghcr.io/cirruslabs/flutter and only open a PR when a newer tag exists — i.e. only when the Docker image is actually available.

No grouping rules are needed because .fvmrc is the only file that carries the pinned version; ci/main.go derives the image tag from it at runtime.

Verification Steps (for the implementer)

  1. After merging, trigger a manual Renovate run (via the renovate.yml workflow dispatch or wait for the daily 0 6 * * * schedule).
  2. Confirm Renovate detects .fvmrc and reports the Flutter dep under ghcr.io/cirruslabs/flutter.
  3. If 3.44.1 is now available on ghcr.io/cirruslabs/flutter, Renovate will open a PR updating .fvmrc; if not, no PR — which is the desired behavior.
I now have a full picture of the problem. Let me write the plan. --- ## Implementation Plan for Issue #447: Renovate Flutter Version Sync ### Problem The Flutter version is declared in exactly one place — `.fvmrc` (`{ "flutter": "3.44.0" }`). The Dagger CI pipeline (`ci/main.go:202`) reads `.fvmrc` at runtime and constructs the Docker image tag `ghcr.io/cirruslabs/flutter:<version>` dynamically. There is no hardcoded version string to keep in sync elsewhere. The real risk: Renovate could bump `.fvmrc` to a version (e.g. `3.44.1`) for which `ghcr.io/cirruslabs/flutter:3.44.1` does not yet exist, causing CI to fail on the image pull. **No grouped-update problem exists** — there is only one file to update. The problem is purely about gating the bump on Docker image availability. --- ### Solution: Custom Renovate Manager Backed by Docker Datasource Add a `customManager` entry to `renovate.json` that: 1. Reads the version string from `.fvmrc`. 2. Uses `ghcr.io/cirruslabs/flutter` as the package with the `docker` datasource. 3. Renovate will only propose a PR if the corresponding image tag actually exists in the registry — solving the availability gating problem. ### Change Required **File: `renovate.json`** — add one entry to `customManagers`: ```json { "customType": "regex", "fileMatch": ["^\\.fvmrc$"], "matchStrings": ["\"flutter\":\\s*\"(?<currentValue>[^\"]+)\""], "depNameTemplate": "ghcr.io/cirruslabs/flutter", "datasourceTemplate": "docker", "versioningTemplate": "semver" } ``` This regex extracts the value of the `"flutter"` key from `.fvmrc`. Renovate will look up available tags for `ghcr.io/cirruslabs/flutter` and only open a PR when a newer tag exists — i.e. only when the Docker image is actually available. No grouping rules are needed because `.fvmrc` is the only file that carries the pinned version; `ci/main.go` derives the image tag from it at runtime. --- ### Verification Steps (for the implementer) 1. After merging, trigger a manual Renovate run (via the `renovate.yml` workflow dispatch or wait for the daily `0 6 * * *` schedule). 2. Confirm Renovate detects `.fvmrc` and reports the Flutter dep under `ghcr.io/cirruslabs/flutter`. 3. If `3.44.1` is now available on `ghcr.io/cirruslabs/flutter`, Renovate will open a PR updating `.fvmrc`; if not, no PR — which is the desired behavior.
guettlibot commented 2026-06-05 20:00:12 +00:00 (Migrated from codeberg.org)
Copy Link
Copy Source

Done. Here's a summary of what was implemented:

What changed: Added a single custom manager entry to renovate.json that reads the Flutter version from .fvmrc and validates new versions against the ghcr.io/cirruslabs/flutter Docker registry.

Why this works: .fvmrc is the only place the Flutter version is pinned — ci/main.go reads it at runtime and constructs the Docker image tag ghcr.io/cirruslabs/flutter:<version> dynamically. No other files need to be grouped or updated. By using the Docker registry as the datasource, Renovate will only open a bump PR when the corresponding image tag actually exists, preventing CI failures from unavailable images (e.g. 3.44.1 not yet published).

Pull request: https://codeberg.org/guettli/sharedinbox/pulls/452

Done. Here's a summary of what was implemented: --- **What changed:** Added a single custom manager entry to `renovate.json` that reads the Flutter version from `.fvmrc` and validates new versions against the `ghcr.io/cirruslabs/flutter` Docker registry. **Why this works:** `.fvmrc` is the only place the Flutter version is pinned — `ci/main.go` reads it at runtime and constructs the Docker image tag `ghcr.io/cirruslabs/flutter:<version>` dynamically. No other files need to be grouped or updated. By using the Docker registry as the datasource, Renovate will only open a bump PR when the corresponding image tag actually exists, preventing CI failures from unavailable images (e.g. `3.44.1` not yet published). **Pull request:** https://codeberg.org/guettli/sharedinbox/pulls/452
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#447