ente-photos 0.2.0: fix public album sharing (#2), add custom CA support (#1)#4
Merged
Merged
Conversation
Two upstream issues addressed: #1 — Custom CA for S3/SMTP TLS verification. A new museum.customCA block mounts a PEM bundle from an existing Secret or ConfigMap at /etc/ssl/certs/custom-ca-bundle.crt and points SSL_CERT_FILE at it. Go's crypto/x509 picks it up automatically, so the museum now trusts private CAs without a rebuild. #2 — Public album sharing landed on a login page because the chart had no albums frontend at all and routed albums.<domain> to the photos app (port 3000) instead of the bundled albums app (port 3002). Root cause: ghcr.io/ente-io/web is a single nginx image that serves each frontend on a different port (photos=3000, accounts=3001, albums=3002, auth=3003, cast=3004, share=3005). The chart hard-coded containerPort=3000 for every web.* block, so accounts/auth/cast/share were all secretly running the photos app. This commit: - Adds a new web.albums component (port 3002) — required for public album sharing - Fixes the default containerPort for accounts (3001), auth (3003), cast (3004), share (3005) - Auto-derives museum.config.apps.publicAlbums / publicLocker / accounts from the matching web.<app>.ingress.hosts[0] - Empties the placeholder *.ente.local defaults in values.yaml so auto-derive kicks in by default - Updates schema and README; bumps chart to 0.2.0
This was referenced May 4, 2026
The previous workflow pinned Python 3.7, which has been EOL since June 2023 and was removed from GitHub-hosted runners — every run failed at the setup-python step before reaching ct lint. Bumps: - actions/checkout@v2 → @v4 - actions/setup-python@v2 (3.7) → @v5 (3.12) - azure/setup-helm@v1 (3.8.1) → @v4 (3.16.3) - helm/chart-testing-action@v2.2.1 → @v2.6.1 - replaces deprecated ::set-output with $GITHUB_OUTPUT Drops the ct install step. Charts in this repo (ente-photos, freescout, chibisafe) require external Postgres / S3 / etc. that is not provisioned in CI; ct install would crashloop the museum pod and fail. Lint coverage stays in place.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes two reported issues in the
ente-photoschart and ships v0.2.0.Fix #1 — custom CA for outbound TLS (S3, SMTP, OIDC)
Adds a new
museum.customCAblock that mounts a PEM bundle from an existing Secret or ConfigMap at/etc/ssl/certs/custom-ca-bundle.crtand pointsSSL_CERT_FILEat it. Go'scrypto/x509readsSSL_CERT_FILEautomatically, so the museum trusts private CAs without rebuilding the image or running an init container.Fix #2 — public album sharing landed on a login page
Root cause was bigger than the issue suggested.
ghcr.io/ente-io/webis a single nginx image that serves each frontend on a separate internal port (photos=3000, accounts=3001, albums=3002, auth=3003, cast=3004, share=3005). The chart hard-codedcontainerPort: 3000for everyweb.*block, so accounts/auth/cast/share were all silently running the photos app, and there was noalbumscomponent at all — which is why `albums.` always landed on the photos login page.This PR:
web.albumscomponent (port 3002) — the only frontend that knows how to render a?t=TOKENpublic album link.containerPortforaccounts(3001),auth(3003),cast(3004),share(3005).museum.config.apps.publicAlbums/publicLocker/accountsfrom the matchingweb.<app>.ingress.hosts[0]. No more keeping three places in sync by hand.Also rolls up
Test plan
Closes #1
Closes #2