Ensure SQLite Web always pulls latest image#1467
Conversation
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/CommunityToolkit/Aspire/main/eng/scripts/dogfood-pr.sh | bash -s -- 1467Or
iex "& { $(irm https://raw.githubusercontent.com/CommunityToolkit/Aspire/main/eng/scripts/dogfood-pr.ps1) } 1467" |
|
@dotnet-policy-service agree |
|
Why not use the last released tag that is |
i was following comment on the code here: and the integration was already using latest, so I don't want to lock it in current release |
|
It looks like a mistake, we should always pin to a release tag. cc. @aaronpowell |
|
Context: When I created the integration (and added the web container support) the project wasn't providing tagged released, it was only providing the Looking at history, that was done on the 15th Jan 2025 and then looking at the sqlite-web project, it would appear that, as of the 16th Jan 2025 they started publishing tagged releases 🤣. Given that, we should be updating so that the container image tags for SqliteWeb is pinned to the latest, which is 0.7.2, and not have the "always pull latest" logic in there. |
Summary
Root cause
The SQLite integration has to use
ghcr.io/coleifer/sqlite-web:latestbecause the image does not publish versioned tags. The resource currently uses the container runtime's default pull policy, which can indefinitely reuse a cachedlatestimage.Older cached images can have a different startup contract from the current image. In particular, an image without an entrypoint receives the database filename from Aspire as its command and fails with
exec: "db.sqlite": executable file not found in $PATH.Using
ImagePullPolicy.Alwayskeeps the mutable image tag and its startup contract in sync for everyWithSqliteWeb()consumer.Validation
The TypeScript AppHost test was excluded locally because the installed Aspire CLI does not provide the repository's expected
aspire restorecommand. It remains covered by CI.