chore: pin collabora/code to 26.04.2.4.1 + Dependabot docker tracking via docker-compose.yml

[petrsvihlik]

Summary

• Pins the collabora/code image from unpinned (latest) to 26.04.2.4.1 — the current latest stable as of 2026-08-01.
• Moves both container image tags (collabora/code, onlyoffice/documentserver) to infra/WopiHost.AppHost/docker-compose.yml so Dependabot's docker ecosystem owns future bumps. Program.cs is not touched by future bumps — only docker-compose.yml is.
• No breaking changes flagged in upstream Collabora release notes (the upstream releases page only publishes Helm chart releases; no CODE-specific notes are available there).

What changed

infra/WopiHost.AppHost/docker-compose.yml (new)
The single source of truth for container image versions. Not used to run containers — exists so Dependabot can track image: lines and open bump PRs.

.github/dependabot.yml
Added a docker ecosystem entry pointed at /infra/WopiHost.AppHost (monthly schedule, 7-day cooldown, matching the nuget/github-actions entries). Dependabot will open future bump PRs that touch only docker-compose.yml.

infra/WopiHost.AppHost/Program.cs
Added ReadContainerImage helper that parses image: from a docker-compose service block and returns (image, tag). Both AddContainer call sites now read from docker-compose.yml instead of hardcoding the strings. onlyoffice/documentserver was also unpinned — it's now in the manifest and Dependabot will open the first pin PR for it too.

infra/WopiHost.AppHost/WopiHost.AppHost.csproj
Added <None Update="docker-compose.yml" CopyToOutputDirectory="PreserveNewest"> so the file is available alongside the AppHost binary at runtime.

Test plan

• dotnet build infra/WopiHost.AppHost
• dotnet run --project infra/WopiHost.AppHost with AppHost:UseCollabora=true, open the Aspire dashboard, confirm the collabora container starts healthy and a document loads in the iframe.
• Confirm Dependabot opens a PR touching only docker-compose.yml on the next monthly cycle (or trigger manually via the Dependabot UI).

[github-actions]

WOPI Validator results

Status	Count
✅ Pass	115
❌ Fail	3
⏭️ Skipped	101

Validator: WopiValidator 2.0.5 (from nuget.org)
Test category: All

📋 Full report and wopi-validator-output artifact ↗

[github-actions]

API Compatibility Report

Compared this PR's packed assemblies against the latest stable release on NuGet.org for each library, honoring each project's CompatibilitySuppressions.xml. This check fails on any public-API break not recorded as intentional — already-suppressed breaks are masked, so what surfaces below is what this PR changes. If a break is deliberate, regenerate and commit the suppressions:

dotnet pack -c Release -p:ApiCompatGenerateSuppressionFile=true

✅ WopiHost.Abstractions vs 9.1.0

No public API breaking changes detected.

✅ WopiHost.Core vs 9.1.0

No public API breaking changes detected.

✅ WopiHost.Discovery vs 9.1.0

No public API breaking changes detected.

✅ WopiHost.Url vs 9.1.0

No public API breaking changes detected.

✅ WopiHost.FileSystemProvider vs 9.1.0

No public API breaking changes detected.

✅ WopiHost.MemoryLockProvider vs 9.1.0

No public API breaking changes detected.

✅ WopiHost.AzureStorageProvider vs 9.1.0

No public API breaking changes detected.

✅ WopiHost.AzureLockProvider vs 9.1.0

No public API breaking changes detected.

---

No unsuppressed public-API breaks across any package.

[qltysh]

Coverage Impact

This PR will not change total coverage.

🚦 See full report on Qlty Cloud »

🛟 Help

• Diff Coverage: Coverage for added or modified lines of code (excludes deleted files). Learn more.

• Total Coverage: Coverage for the whole repository, calculated as the sum of all File Coverage. Learn more.

• File Coverage: Covered Lines divided by Covered Lines plus Missed Lines. (Excludes non-executable lines including blank lines and comments.)

  • Indirect Changes: Changes to File Coverage for files that were not modified in this PR. Learn more.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.31%. Comparing base (8bee3a5) to head (527957c).
⚠️ Report is 9 commits behind head on master.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #623   +/-   ##
=======================================
  Coverage   93.31%   93.31%           
=======================================
  Files         125      125           
  Lines        4906     4906           
  Branches      599      599           
=======================================
  Hits         4578     4578           
  Misses        169      169           
  Partials      159      159           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

[petrsvihlik]

@claude will dependabot be able to update this in the future?

[claude]

Claude finished @petrsvihlik's task in 40s —— View job

---

Will Dependabot pick up future collabora/code bumps?

No, not as things stand today. Two separate gaps:

1. No docker ecosystem is configured. .github/dependabot.yml only declares nuget and github-actions update entries — there's no package-ecosystem: docker block at all.
2. Even if one were added, it wouldn't see this reference. Dependabot's docker ecosystem only parses Dockerfiles and docker-compose.yml/docker-bake.hcl files for image tags. The Collabora image here isn't declared in any of those — it's a string literal passed to Aspire's C# API:

   // infra/WopiHost.AppHost/Program.cs:262
   var collabora = builder.AddContainer("collabora", "collabora/code", "26.04.2.4.1")

   Dependabot has no source-code/regex-based scanner for arbitrary files (unlike Renovate's customManagers/regexManagers, which can be pointed at a .cs file with a match pattern). So a plain .github/dependabot.yml docker entry would have nothing to scan and wouldn't touch this line. The same gap applies to the unpinned onlyoffice/documentserver image at Program.cs:323.

Options if you want this automated:

• Switch (or add) Renovate, which supports customManagers to regex-match version strings inside arbitrary source files — it could target the AddContainer("collabora", "collabora/code", "...") call directly.
• Move the image+tag into a docker-compose.yml fragment or a small Directory.Build.props-style version file that Dependabot's docker ecosystem (or a custom script) can parse — bigger refactor, probably not worth it just for this.
• Keep it manual, as this PR does — reasonable given there are only two hardcoded image tags in the whole AppHost.

No code changes were made — this was a question, not an implementation request.

[petrsvihlik]

Unfortunately no — for two reasons:

1. .dependabot.yml has no docker ecosystem entry. Adding one would only cover Dockerfile and docker-compose.yml files.
2. Dependabot's Docker support doesn't parse C# source. The image reference is a string literal in Program.cs passed to builder.AddContainer(...), which Dependabot never looks at regardless of ecosystem configuration.

The monthly scheduled check that opened this PR is the right mechanism here.

---

Generated by Claude Code

[petrsvihlik]

@claude can this be refactored so that the version of the image is fixed somewhere where dependabot can update it and c# code remains untouched?

[claude]

Claude finished @petrsvihlik's task in 1m 17s —— View job

---

Can this be refactored so Dependabot can bump it without touching C#?

• Read trigger comment and prior discussion in this thread
• Check current AddContainer usage in Program.cs and .github/dependabot.yml
• Assess whether a refactor can let Dependabot bump the image tag without touching C#
• Post recommendation

Short answer: yes, but only by introducing a file Dependabot's docker-compose ecosystem actually parses — there's no way to make it read a plain C# literal, JSON config value, or MSBuild props file.

Dependabot's docker support is narrow: it only scans files that are literally named Dockerfile* or docker-compose.yml/.yaml, looking for image:/FROM lines. It has no regex/custom-manager mechanism (that's a Renovate-only feature), so moving the tag into appsettings.json, a .props file, or an env var doesn't help — none of those are formats Dependabot's docker updater understands.

The only refactor that would actually work:

1. Add a docker-compose.yml (or a small dedicated manifest, e.g. infra/WopiHost.AppHost/containers.docker-compose.yml) that isn't used to run anything — its sole purpose is to pin image: collabora/code:26.04.2.4.1 and image: onlyoffice/documentserver:<tag> in a shape Dependabot recognizes.
2. Add a package-ecosystem: docker-compose entry to .github/dependabot.yml pointed at that file's directory.
3. Have Program.cs read the tag out of that file at startup (a small one-time parse — a regex or a minimal YAML read against the image: line) instead of hardcoding "26.04.2.4.1" at Program.cs:262 / the missing tag at Program.cs:323.

After that one-time change, future bumps are Dependabot PRs that touch only the compose manifest — Program.cs stays untouched, as you asked.

Trade-off worth weighing before I build this: it adds a file whose only job is to exist for a bot to parse (nothing in the repo actually runs it), plus a small startup-time parser in Program.cs that has to keep working correctly (wrong parse = AppHost silently pulls the wrong/no tag). For two hardcoded image references, that's a real but non-trivial amount of indirection for the win of "one less line to hand-edit twice a year." The alternative raised earlier in this thread — switching to Renovate with a customManager regex targeting AddContainer("collabora", "collabora/code", "...") directly — gets the same automation with zero C# refactor, at the cost of introducing a second bot alongside Dependabot.

Given the trade-off, let me know which direction you'd like:

• (A) Implement the docker-compose-manifest + parser approach (keeps Dependabot as the only bot, but adds the indirection described above), or
• (B) Leave this as a documented option and continue with manual/monthly bumps (lowest complexity, status quo).

I haven't made any code changes yet — happy to implement (A) on this branch if that's the direction you want.

[petrsvihlik]

The cleanest path depends on whether you're willing to add Renovate or stay Dependabot-only:

Option A — Renovate (recommended, zero structural change)

Renovate's regexManagers can match version strings in arbitrary source files, including .cs. A renovate.json entry like:

{
  "regexManagers": [
    {
      "fileMatch": ["^infra/WopiHost\\.AppHost/Program\\.cs$"],
      "matchStrings": [
        "AddContainer\\(\"collabora\", \"collabora/code\", \"(?<currentValue>[^\"]+)\""
      ],
      "depNameTemplate": "collabora/code",
      "datasourceTemplate": "docker"
    }
  ]
}

would open PRs that patch just the version string in Program.cs — no file-format refactor, no extra config file to keep in sync.

Option B — Stay Dependabot, one-time C# refactor

Move the image tags to appsettings.json in the AppHost and have C# read from there. Add a Dockerfile stub (FROM collabora/code:26.04.2.4.1) that Dependabot's docker ecosystem tracks, plus a CI check that the appsettings.json value matches. Future Dependabot PRs touch the Dockerfile; a human (or a small CI step) keeps appsettings.json in sync.

That's a one-time C# change now to avoid C# changes forever, but it introduces a two-file sync burden unless the CI enforces it.

Recommendation: Given there are only two hardcoded image tags in the whole AppHost, the Renovate regexManagers route is the least invasive. The monthly scheduled check that opened this PR is a reasonable fallback if neither option is appealing right now.

---

Generated by Claude Code

[petrsvihlik]

@claude ok, use option A and refactor everything in this PR

[claude]

Claude finished @petrsvihlik's task in 4m 24s —— View job

---

Renovate custom regex manager — implemented, but push blocked

• Gather context (Program.cs, .github/dependabot.yml, confirmed no existing Renovate config)
• Add renovate.json with a customManagers regex entry for collabora/code
• Scope Renovate to only that manager (enabledManagers: ["custom.regex"]) so it doesn't duplicate Dependabot's NuGet/GitHub Actions coverage
• Verify the regex against the current Program.cs:262 literal
• Push to branch — blocked, see below

What was built

Added renovate.json at the repo root:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "enabledManagers": ["custom.regex"],
  "customManagers": [
    {
      "customType": "regex",
      "description": "collabora/code's image tag in infra/WopiHost.AppHost/Program.cs is a C# string literal passed to Aspire's builder.AddContainer(...) call. Dependabot's docker ecosystem only parses Dockerfile/docker-compose.yml files (see .github/dependabot.yml) and never sees a reference embedded in source, so this tracks that one literal directly. enabledManagers above keeps Renovate scoped to just this manager — NuGet and GitHub Actions stay owned by Dependabot to avoid duplicate PRs for the same dependency.",
      "fileMatch": ["^infra/WopiHost\\.AppHost/Program\\.cs$"],
      "matchStrings": [
        "AddContainer\\(\"collabora\", \"collabora/code\", \"(?<currentValue>[^\"]+)\"\\)"
      ],
      "depNameTemplate": "collabora/code",
      "datasourceTemplate": "docker"
    }
  ],
  "packageRules": [
    {
      "matchDepNames": ["collabora/code"],
      "commitMessagePrefix": "chore(deps)",
      "labels": ["devops"]
    }
  ]
}

Program.cs itself is untouched, as requested — Renovate will patch just the version string in place, the same way it does today.

enabledManagers is the load-bearing line. Without it, adding a Renovate config would make Renovate also try to manage NuGet/GitHub Actions on top of what Dependabot already owns (.github/dependabot.yml) — the "second bot" trade-off flagged earlier in this thread. Restricting to custom.regex keeps Renovate scoped to exactly the one gap Dependabot can't cover.

Scoped out (flagging, not implementing)

• onlyoffice/documentserver at Program.cs:323 isn't covered — it's currently unpinned (AddContainer("onlyoffice", "onlyoffice/documentserver"), no tag), so there's no version literal for a regex manager to extract/bump. Covering it would first require pinning it to an explicit tag, which is a separate reproducibility change beyond "wire up tracking for the version this PR bumps." Happy to do that as a follow-up if wanted.
• Dependabot auto-merge (.github/workflows/dependabot-auto-merge.yml) gates on github.actor == 'dependabot[bot]', so Renovate PRs for this manager won't auto-merge like Dependabot's do. I can't edit workflow files (blocked by GitHub App permissions on this bot) — if you want parity, that gate needs a manual edit to also allow renovate[bot].
• The Renovate GitHub App itself isn't installed on this repo as far as I can tell from the file tree — a renovate.json alone doesn't activate anything; the app (or self-hosted runner) needs to be enabled for petrsvihlik/WopiHost for this config to take effect.
• I don't have live internet access in this session to double-check the customManagers/fileMatch field names against Renovate's latest schema — this matches the stable, documented shape as I know it, but Renovate's own config-validator check (once the app is installed) will flag it immediately if a field name has since been renamed.

Push blocked — needs your attention

The change is committed locally (94aae3d, on top of a0e7794) but pushing to this branch fails:

remote: Permission to petrsvihlik/WopiHost.git denied to github-actions[bot].
fatal: unable to access 'https://github.com/petrsvihlik/WopiHost.git/': The requested URL returned error: 403

This happens on every retry, so it isn't transient — the token this job is authenticating with resolves to github-actions[bot], which doesn't have write access here (independent of my file changes). This is likely a permissions: scope issue on the workflow that runs this job (.github/workflows/claude.yml), which I'm not permitted to edit. Since I can't get the commit onto the branch, the renovate.json content above is included in full so you can add it directly if you'd like to keep it out of a manual apply.
·

[petrsvihlik]

Done — pushed as a second commit on this branch. Here's what changed:

New file: infra/WopiHost.AppHost/docker-compose.yml
Contains image: lines for collabora/code:26.04.2.4.1 and onlyoffice/documentserver (currently unpinned — Dependabot will open the first pin PR for it). This is the only file future bumps will touch.

.github/dependabot.yml
Added a docker ecosystem entry pointing at /infra/WopiHost.AppHost with a monthly schedule and 7-day cooldown, matching the existing nuget/github-actions entries.

infra/WopiHost.AppHost/Program.cs
Added ReadContainerImage helper (parses image: from a service block via regex) and updated both AddContainer call sites to read from the compose file at AppContext.BaseDirectory. The method chain on each container resource builder is correctly applied to both branches of the ternary by wrapping it in parentheses.

infra/WopiHost.AppHost/WopiHost.AppHost.csproj
Added CopyToOutputDirectory=PreserveNewest for docker-compose.yml so it's beside the binary at runtime.

The automated bot (claude[bot]) implemented Renovate regexManagers instead — that approach leaves Program.cs as the source of truth and is also valid, but requires installing the Renovate GitHub App. I went with the Dependabot docker-compose approach since you specifically asked about Dependabot.

---

Generated by Claude Code

[petrsvihlik]

Superseded by #624, which implements the Renovate custom-manager approach chosen in this thread: the image tags stay as literals in Program.cs (collabora/code pinned to 26.04.2.4.1, onlyoffice/documentserver pinned to 9.4.0.1) and Renovate patches them in place — no compose manifest, no startup parser. Note for archaeology: the docker-compose approach here would also have needed package-ecosystem: docker-compose (not docker) for Dependabot to parse the compose file.