chore: upgrade app to 2026.7.1, redis to 8.10-alpine #6

Closed

autonomic-bot wants to merge 0 commits from upgrade-c10c04c into main

pull from: upgrade-c10c04c

merge into: :main

:main

:upgrade-c10c04c

:fix-redis-host

:discourse-official

:discourse-official-image

:fix-pg-migration-idempotent

:ci/bitnamilegacy-repin

:renovate/configure

:cas_readme

Conversation 27 Commits - Files Changed -

autonomic-bot commented 2026-06-19 02:29:59 +00:00

Owner

Copy Link

Copy Source

Discourse upgrade — app 3.5.3 → 2026.7.1 (ESR jump) + redis 7.4-alpine → 8.10-alpine. postgres stays at discourse/postgres:pg18 (newest pg major; no pg19).

Re-verified 2026-08-07: all three images confirmed at their newest compatible tags (abra-trusted for app+redis; direct Docker-Hub check for the abra-unparseable pg18 sidecar — pg13..pg18 all re-pushed 2026-08-04, no pg19). PR #6 head already equals the current upgrade; this run re-triggers !testme now that cc-ci PR #15 (UPGRADE_BASE_FLOOR recipe_meta key + version-agnostic faithfulness test) is merged.

service	image	old (upstream main)	new
app	discourse/discourse	3.5.3	2026.7.1 (ESR)
db	discourse/postgres	pg18	pg18 (unchanged)
redis	redis	7.4-alpine	8.10-alpine

Upstream release notes:

• app discourse 3.5.3 to 2026.7.1 (ESR jump): https://releases.discourse.org/changelog/v2026.7.1/ , https://releases.discourse.org/changelog/v2026.7.0/ ; community jump guide https://meta.discourse.org/t/jumping-from-2026-1-esr-to-2026-7-what-i-found/408779
• redis 7.4-alpine to 8.10-alpine: https://raw.githubusercontent.com/redis/redis/8.0/00-RELEASENOTES
• db discourse/postgres pg18: https://github.com/discourse/discourse-postgres (tags pg13..pg18; non-semver)

Operator action required (ESR jump): 6-month ESR jump with web-server swap (Unicorn to Pitchfork, internal), default-on behavior changes via the new Upcoming Changes opt-out system (Discourse Reactions, Uncategorized removal, rich_editor setting gone), and theme deprecations (.hbs, .js.es6, legacy widget shims) — operator-facing for sites with custom themes. Postgres pg18 is fine (auto-upgrades in place on boot); no DB dump/restore needed. See release/next for the bitnami to official env-var renames if upgrading from a pre-1.0.0 deploy.

Recommended release (operator, after merge): abra recipe release discourse -x (major — ESR jump + web-server swap + default-on changes + deprecations). The version label is NOT bumped in this PR.

NOT merged — for operator review. cc @trav @notplants

Discourse upgrade — app 3.5.3 → 2026.7.1 (ESR jump) + redis 7.4-alpine → 8.10-alpine. postgres stays at discourse/postgres:pg18 (newest pg major; no pg19). Re-verified 2026-08-07: all three images confirmed at their newest compatible tags (abra-trusted for app+redis; direct Docker-Hub check for the abra-unparseable pg18 sidecar — pg13..pg18 all re-pushed 2026-08-04, no pg19). PR #6 head already equals the current upgrade; this run re-triggers !testme now that cc-ci PR #15 (UPGRADE_BASE_FLOOR recipe_meta key + version-agnostic faithfulness test) is merged. | service | image | old (upstream main) | new | |---------|---------------------|---------------------|------------------| | app | discourse/discourse | 3.5.3 | 2026.7.1 (ESR) | | db | discourse/postgres | pg18 | pg18 (unchanged) | | redis | redis | 7.4-alpine | 8.10-alpine | Upstream release notes: - app discourse 3.5.3 to 2026.7.1 (ESR jump): https://releases.discourse.org/changelog/v2026.7.1/ , https://releases.discourse.org/changelog/v2026.7.0/ ; community jump guide https://meta.discourse.org/t/jumping-from-2026-1-esr-to-2026-7-what-i-found/408779 - redis 7.4-alpine to 8.10-alpine: https://raw.githubusercontent.com/redis/redis/8.0/00-RELEASENOTES - db discourse/postgres pg18: https://github.com/discourse/discourse-postgres (tags pg13..pg18; non-semver) Operator action required (ESR jump): 6-month ESR jump with web-server swap (Unicorn to Pitchfork, internal), default-on behavior changes via the new Upcoming Changes opt-out system (Discourse Reactions, Uncategorized removal, rich_editor setting gone), and theme deprecations (.hbs, .js.es6, legacy widget shims) — operator-facing for sites with custom themes. Postgres pg18 is fine (auto-upgrades in place on boot); no DB dump/restore needed. See release/next for the bitnami to official env-var renames if upgrading from a pre-1.0.0 deploy. Recommended release (operator, after merge): abra recipe release discourse -x (major — ESR jump + web-server swap + default-on changes + deprecations). The version label is NOT bumped in this PR. NOT merged — for operator review. cc @trav @notplants

autonomic-bot added 1 commit 2026-06-19 02:30:01 +00:00

chore: upgrade redis 7.4-alpine -> 8.8-alpine c10c04c520

autonomic-bot requested review from trav 2026-06-19 02:30:02 +00:00

autonomic-bot requested review from notplants 2026-06-19 02:30:02 +00:00

autonomic-bot commented 2026-06-19 02:30:23 +00:00

Author

Owner

Copy Link

Copy Source

!testme

!testme

autonomic-bot commented 2026-06-19 02:30:39 +00:00

Author

Owner

Copy Link

Copy Source

🌻 cc-ci — discourse @ c10c04c5 ❌ failure

full logs · dashboard

<!-- cc-ci:testme --> 🌻 **cc-ci** — `discourse` @ `c10c04c5` ❌ **failure** [](https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/929) [](https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/929) [full logs](https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/929) · [dashboard](https://ci.commoninternet.net/)

autonomic-bot commented 2026-06-19 02:46:05 +00:00

Author

Owner

Copy Link

Copy Source

!testme RED — upgrade is correct, but cc-ci upgrade tests gate the official-image migration\n\nThe redis 7.4-alpine → 8.8-alpine upgrade is correct and validated (chaos deploy confirmed Redis 8.8 loaded the 7.4.9 RDB cleanly, 258 keys, no errors). The failure is in the cc-ci upgrade tier, not in the upgrade itself.\n\nFailing tests:\n- tests/discourse/test_upgrade.py::test_head_runs_official_image_not_bitnamilegacy\n- tests/discourse/test_upgrade.py::test_sidekiq_service_dropped_by_head\n\nWhy they fail: These tests were added to cc-ci specifically to gate the PR #5 (discourse-official-image) migration. They assert any discourse upgrade PR head must:\n1. Run discourse/discourse:3.5.3 (not bitnamilegacy/discourse)\n2. Have the sidekiq service dropped (the official image handles Sidekiq in-process)\n\nThis PR only upgrades redis; it does not switch the discourse image. The upgrade tier therefore fails because our PR head still uses bitnamilegacy/discourse:3.5.0.\n\nContext:\n- bitnamilegacy/discourse is frozen at 3.5.0 -- the 9.x tags abra reports are Helm chart OCI artifacts, not container images.\n- PR #5 (discourse-official-image, already GREEN Drone 928) is the real discourse image upgrade.\n- The cc-ci upgrade tests gate that migration specifically -- a redis-only bump on bitnamilegacy cannot pass them without the image switch.\n\nOperator options:\n1. Merge PR #5 first -- then a new redis upgrade PR (rebased on the official-image compose.yml) would pass.\n2. Re-run /recipe-upgrade discourse --with-tests -- opens a cc-ci test PR to relax these assertions for independent redis upgrades.\n\nNothing was merged.

## !testme RED — upgrade is correct, but cc-ci upgrade tests gate the official-image migration\n\nThe redis 7.4-alpine → 8.8-alpine upgrade is **correct and validated** (chaos deploy confirmed Redis 8.8 loaded the 7.4.9 RDB cleanly, 258 keys, no errors). The failure is in the cc-ci upgrade tier, not in the upgrade itself.\n\n**Failing tests:**\n- `tests/discourse/test_upgrade.py::test_head_runs_official_image_not_bitnamilegacy`\n- `tests/discourse/test_upgrade.py::test_sidekiq_service_dropped_by_head`\n\n**Why they fail:** These tests were added to cc-ci specifically to gate the PR #5 (discourse-official-image) migration. They assert any discourse upgrade PR head must:\n1. Run `discourse/discourse:3.5.3` (not `bitnamilegacy/discourse`)\n2. Have the `sidekiq` service dropped (the official image handles Sidekiq in-process)\n\nThis PR only upgrades redis; it does not switch the discourse image. The upgrade tier therefore fails because our PR head still uses `bitnamilegacy/discourse:3.5.0`.\n\n**Context:**\n- `bitnamilegacy/discourse` is frozen at 3.5.0 -- the 9.x tags abra reports are Helm chart OCI artifacts, not container images.\n- PR #5 (`discourse-official-image`, already GREEN Drone 928) is the real discourse image upgrade.\n- The cc-ci upgrade tests gate that migration specifically -- a redis-only bump on bitnamilegacy cannot pass them without the image switch.\n\n**Operator options:**\n1. **Merge PR #5 first** -- then a new redis upgrade PR (rebased on the official-image compose.yml) would pass.\n2. **Re-run `/recipe-upgrade discourse --with-tests`** -- opens a cc-ci test PR to relax these assertions for independent redis upgrades.\n\nNothing was merged.

autonomic-bot commented 2026-06-22 21:06:54 +00:00

Author

Owner

Copy Link

Copy Source

!testme

!testme

autonomic-bot commented 2026-06-22 21:07:02 +00:00

Author

Owner

Copy Link

Copy Source

🌻 cc-ci — discourse @ c10c04c5 ❌ failure

full logs · dashboard

<!-- cc-ci:testme --> 🌻 **cc-ci** — `discourse` @ `c10c04c5` ❌ **failure** [](https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/948) [](https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/948) [full logs](https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/948) · [dashboard](https://ci.commoninternet.net/)

autonomic-bot commented 2026-06-22 21:16:34 +00:00

Author

Owner

Copy Link

Copy Source

!testme RED (build 948) — upgrade correct; two cc-ci tests are stale for this PR (DEFAULT mode: comment, no test edits)

The redis 7.4-alpine → 8.8-alpine upgrade is correct and verified. The RED is from two cc-ci upgrade-tier tests that assert a different PR's behaviour, not from this upgrade.

Evidence the upgrade itself works

• tests/_generic/test_upgrade.py::test_upgrade_reconverges — PASSED (build 948, upgrade__generic__test_upgrade.xml: 0 failures, 1 passed). The generic upgrade tier confirms the base→head redeploy reconverges and serves.
• Chaos deploy of this PR head (commit 328d871) — converged & served on dev-discourse.ci.commoninternet.net: redis:8.8-alpine → redis_version:8.8.0, BGSAVE OK (214 keys); bitnamilegacy/discourse:3.5.0 app → /srv/status 200 OK; sidekiq actively processing jobs against redis 8.8. (Torn down cleanly.)

The two failing tests (stale for this PR)

tests/discourse/test_upgrade.py — both fail by design on this PR:

1. test_head_runs_official_image_not_bitnamilegacy — asserts the head's app image must be discourse/discourse:3.5.3. This PR keeps bitnamilegacy/discourse:3.5.0 (the image the recipe currently ships). Failure: app image is 'bitnamilegacy/discourse:3.5.0@sha256:...'.
2. test_sidekiq_service_dropped_by_head — asserts the head must drop the sidekiq service. This PR keeps sidekiq. Failure: sidekiq service still present ... ['app','db','redis','sidekiq'].

These tests were written to gate PR #5 (discourse-official-image) — the migration to the official discourse/discourse image, which drops sidekiq (it runs in-process). They assert that migration's specific shape on every discourse upgrade PR head. A redis-only bump on the bitnamilegacy path (this PR) cannot satisfy them without switching the app image, which is out of scope here.

Why this PR does not switch the app image

abra recipe upgrade suggests bitnamilegacy/discourse:3.5.0 → 9.0.4/9.0.3. Direct Docker Hub inspection (2026-06-22) confirms those are Helm chart OCI artifacts (media_type: application/vnd.cncf.helm.config.v1+json, ~186 KB, tag_status: inactive, 0 images) — not runnable container images. bitnamilegacy/discourse is frozen at 3.5.0 (newest runnable tag, 2025-08-22; no 3.5.x patch tags). There is no app/sidekiq image upgrade on this path. The real app image upgrade is PR #5 (already GREEN) / PR #7. This PR intentionally stays on the bitnamilegacy path and bumps the one in-scope image with a real upgrade: redis.

Operator options

• Re-run /recipe-upgrade discourse --with-tests to open + verify a cc-ci test-update PR that relaxes the two assertions for the redis-only (bitnamilegacy) upgrade track (DEFAULT mode, which this run used, does not edit tests).
• Or merge PR #5 first (official image) and rebase this redis bump onto it — then the two tests pass on the combined head.

The redis upgrade is independently mergeable and safe (Redis 8 loads 7.x RDBs transparently; Discourse uses Redis only as cache/queue). Nothing was merged.

## !testme RED (build 948) — upgrade correct; two cc-ci tests are stale for this PR (DEFAULT mode: comment, no test edits) The redis `7.4-alpine → 8.8-alpine` upgrade is **correct and verified**. The RED is from two cc-ci upgrade-tier tests that assert a *different* PR's behaviour, not from this upgrade. ### Evidence the upgrade itself works - **`tests/_generic/test_upgrade.py::test_upgrade_reconverges` — PASSED** (build 948, `upgrade__generic__test_upgrade.xml`: 0 failures, 1 passed). The generic upgrade tier confirms the base→head redeploy reconverges and serves. - **Chaos deploy of this PR head (commit 328d871) — converged & served** on `dev-discourse.ci.commoninternet.net`: `redis:8.8-alpine` → `redis_version:8.8.0`, BGSAVE OK (214 keys); `bitnamilegacy/discourse:3.5.0` app → `/srv/status` 200 OK; sidekiq actively processing jobs against redis 8.8. (Torn down cleanly.) ### The two failing tests (stale for this PR) `tests/discourse/test_upgrade.py` — both fail by design on this PR: 1. `test_head_runs_official_image_not_bitnamilegacy` — asserts the head's `app` image **must be `discourse/discourse:3.5.3`**. This PR keeps `bitnamilegacy/discourse:3.5.0` (the image the recipe currently ships). Failure: `app image is 'bitnamilegacy/discourse:3.5.0@sha256:...'`. 2. `test_sidekiq_service_dropped_by_head` — asserts the head **must drop the `sidekiq` service**. This PR keeps sidekiq. Failure: `sidekiq service still present ... ['app','db','redis','sidekiq']`. These tests were written to gate **PR #5 (`discourse-official-image`)** — the migration to the official `discourse/discourse` image, which drops sidekiq (it runs in-process). They assert that migration's specific shape on *every* discourse upgrade PR head. A redis-only bump on the bitnamilegacy path (this PR) cannot satisfy them without switching the app image, which is out of scope here. ### Why this PR does not switch the app image `abra recipe upgrade` suggests `bitnamilegacy/discourse:3.5.0 → 9.0.4/9.0.3`. Direct Docker Hub inspection (2026-06-22) confirms those are **Helm chart OCI artifacts** (`media_type: application/vnd.cncf.helm.config.v1+json`, ~186 KB, `tag_status: inactive`, 0 images) — **not runnable container images**. `bitnamilegacy/discourse` is **frozen at 3.5.0** (newest runnable tag, 2025-08-22; no `3.5.x` patch tags). There is no app/sidekiq image upgrade on this path. The real app image upgrade is PR #5 (already GREEN) / PR #7. This PR intentionally stays on the bitnamilegacy path and bumps the one in-scope image with a real upgrade: redis. ### Operator options - **Re-run `/recipe-upgrade discourse --with-tests`** to open + verify a cc-ci test-update PR that relaxes the two assertions for the redis-only (bitnamilegacy) upgrade track (DEFAULT mode, which this run used, does not edit tests). - **Or merge PR #5 first** (official image) and rebase this redis bump onto it — then the two tests pass on the combined head. The redis upgrade is independently mergeable and safe (Redis 8 loads 7.x RDBs transparently; Discourse uses Redis only as cache/queue). Nothing was merged.

autonomic-bot commented 2026-07-03 02:54:34 +00:00

Author

Owner

Copy Link

Copy Source

!testme

!testme

autonomic-bot commented 2026-07-03 02:54:55 +00:00

Author

Owner

Copy Link

Copy Source

🌻 cc-ci — discourse @ c10c04c5 ❌ failure

full logs · dashboard

<!-- cc-ci:testme --> 🌻 **cc-ci** — `discourse` @ `c10c04c5` ❌ **failure** [](https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/972) [](https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/972) [full logs](https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/972) · [dashboard](https://ci.commoninternet.net/)

autonomic-bot commented 2026-07-03 03:05:04 +00:00

Author

Owner

Copy Link

Copy Source

!testme RED (build 972, 2026-07-03) — upgrade correct; two cc-ci tests are stale for this redis-only PR (DEFAULT mode: comment, no test edits)

Re-verified today (2026-07-03). The redis 7.4-alpine → 8.8-alpine upgrade is correct and independently confirmed; the !testme RED is from the same two cc-ci upgrade-tier tests that gate a different PR's behaviour, not from this upgrade.

Evidence the upgrade itself works (re-verified today)

• Chaos deploy of this PR head (commit c10c04c5) on dev-discourse.ci.commoninternet.net — converged:
  • redis:8.8-alpine → logs show Loading RDB produced by version 7.4.9 → Done loading RDB, keys loaded: 269, keys expired: 0. → Ready to accept connections tcp. Redis 8.8 loaded the 7.4 RDB cleanly (the built-in ReJSON module loads but is unused by Discourse). BGSAVE OK (276 keys).
  • sidekiq (bitnamilegacy/discourse:3.5.0) 1/1 — actively connected to redis 8.8 (message_bus/backends/redis processing global backlog; redis-client calls succeeding).
  • app (bitnamilegacy/discourse:3.5.0) bootstrapping normally — Running database migrations → Precompiling assets (slow discourse startup, no errors).
  • Torn down cleanly (0 stacks, 0 volumes).
• (Build 948, same head c10c04c5, also had tests/_generic/test_upgrade.py::test_upgrade_reconverges — PASSED. Head unchanged since.)

Why app/sidekiq were NOT bumped to abra's suggested 9.0.4 (re-confirmed today)

abra recipe upgrade reports bitnamilegacy/discourse:3.5.0 → 9.0.4 / 9.0.3. Direct Docker Hub API inspection (2026-07-03) confirms these are Helm chart OCI artifacts, NOT runnable container images:

tag	media_type	size	images	tag_status
9.0.4	application/vnd.cncf.helm.config.v1+json	~186 KB	0	inactive
9.0.3	application/vnd.cncf.helm.config.v1+json	~186 KB	0	inactive
3.5.0	application/vnd.docker.distribution.manifest.list.v2+json	831 MB	2 (amd64+arm64)	active

3.5.0 is the last runnable tag (2025-08-22); no runnable tags exist above it (only Helm chart artifacts + 3.4.x below). Bumping app/sidekiq to 9.x would break the deploy. The real app-image upgrade is the official discourse/discourse image, tracked in PR #5 (discourse-official-image) / PR #7 — a base-image migration, out of scope for this redis bump.

The two failing tests (stale for this PR — confirmed by reading the test source)

tests/discourse/test_upgrade.py — the module docstring states these assert the official-image migration (PR #5) genuinely ran on the head:

1. test_head_runs_official_image_not_bitnamilegacy — asserts image.startswith("discourse/discourse:3.5.3") AND "bitnamilegacy" not in image. This PR keeps bitnamilegacy/discourse:3.5.0 (the image the recipe currently ships). Fails by design.
2. test_sidekiq_service_dropped_by_head — asserts "sidekiq" not in services. This PR keeps sidekiq (the bitnamilegacy path runs sidekiq as a separate service). Fails by design.

These tests were written to gate PR #5 — the migration to the official discourse/discourse image (which drops sidekiq, running it in-process). They assert that migration's specific shape on every discourse upgrade PR head. A redis-only bump on the bitnamilegacy path (this PR) cannot satisfy them without switching the app image, which is out of scope here and is the subject of PR #5/#7.

Operator options

• Re-run /recipe-upgrade discourse --with-tests to open + verify a cc-ci test-update PR that relaxes these two assertions for the redis-only (bitnamilegacy) upgrade track (DEFAULT mode, which this run used, does not edit tests).
• Or merge PR #5 first (official image) and rebase this redis bump onto it — then the two tests pass on the combined head.

The redis upgrade is independently mergeable and safe (Redis 8 loads 7.x RDBs transparently; Discourse uses Redis only as cache/queue, no persistence modules). Nothing was merged.

## !testme RED (build 972, 2026-07-03) — upgrade correct; two cc-ci tests are stale for this redis-only PR (DEFAULT mode: comment, no test edits) Re-verified today (2026-07-03). The redis `7.4-alpine → 8.8-alpine` upgrade is **correct and independently confirmed**; the `!testme` RED is from the same two cc-ci upgrade-tier tests that gate a **different** PR's behaviour, not from this upgrade. ### Evidence the upgrade itself works (re-verified today) - **Chaos deploy of this PR head (commit `c10c04c5`) on `dev-discourse.ci.commoninternet.net`** — converged: - `redis:8.8-alpine` → logs show `Loading RDB produced by version 7.4.9` → `Done loading RDB, keys loaded: 269, keys expired: 0.` → `Ready to accept connections tcp`. Redis 8.8 loaded the 7.4 RDB cleanly (the built-in ReJSON module loads but is unused by Discourse). `BGSAVE` OK (276 keys). - `sidekiq` (`bitnamilegacy/discourse:3.5.0`) 1/1 — actively connected to redis 8.8 (`message_bus/backends/redis` processing global backlog; `redis-client` calls succeeding). - `app` (`bitnamilegacy/discourse:3.5.0`) bootstrapping normally — `Running database migrations` → `Precompiling assets` (slow discourse startup, no errors). - Torn down cleanly (0 stacks, 0 volumes). - (Build 948, same head `c10c04c5`, also had `tests/_generic/test_upgrade.py::test_upgrade_reconverges` — PASSED. Head unchanged since.) ### Why app/sidekiq were NOT bumped to abra's suggested `9.0.4` (re-confirmed today) `abra recipe upgrade` reports `bitnamilegacy/discourse:3.5.0 → 9.0.4 / 9.0.3`. **Direct Docker Hub API inspection (2026-07-03)** confirms these are **Helm chart OCI artifacts, NOT runnable container images**: | tag | media_type | size | images | tag_status | |-----|-----------|------|--------|-----------| | `9.0.4` | `application/vnd.cncf.helm.config.v1+json` | ~186 KB | 0 | inactive | | `9.0.3` | `application/vnd.cncf.helm.config.v1+json` | ~186 KB | 0 | inactive | | `3.5.0` | `application/vnd.docker.distribution.manifest.list.v2+json` | 831 MB | 2 (amd64+arm64) | active | `3.5.0` is the **last runnable tag** (2025-08-22); no runnable tags exist above it (only Helm chart artifacts + `3.4.x` below). Bumping app/sidekiq to `9.x` would break the deploy. The real app-image upgrade is the official `discourse/discourse` image, tracked in **PR #5** (`discourse-official-image`) / **PR #7** — a base-image migration, out of scope for this redis bump. ### The two failing tests (stale for this PR — confirmed by reading the test source) `tests/discourse/test_upgrade.py` — the module docstring states these assert the **official-image migration** (PR #5) genuinely ran on the head: 1. `test_head_runs_official_image_not_bitnamilegacy` — asserts `image.startswith("discourse/discourse:3.5.3")` AND `"bitnamilegacy" not in image`. This PR keeps `bitnamilegacy/discourse:3.5.0` (the image the recipe currently ships). Fails by design. 2. `test_sidekiq_service_dropped_by_head` — asserts `"sidekiq" not in services`. This PR keeps sidekiq (the bitnamilegacy path runs sidekiq as a separate service). Fails by design. These tests were written to gate **PR #5** — the migration to the official `discourse/discourse` image (which drops sidekiq, running it in-process). They assert that migration's specific shape on *every* discourse upgrade PR head. A redis-only bump on the bitnamilegacy path (this PR) cannot satisfy them without switching the app image, which is out of scope here and is the subject of PR #5/#7. ### Operator options - **Re-run `/recipe-upgrade discourse --with-tests`** to open + verify a cc-ci test-update PR that relaxes these two assertions for the redis-only (bitnamilegacy) upgrade track (DEFAULT mode, which this run used, does not edit tests). - **Or merge PR #5 first** (official image) and rebase this redis bump onto it — then the two tests pass on the combined head. The redis upgrade is independently mergeable and safe (Redis 8 loads 7.x RDBs transparently; Discourse uses Redis only as cache/queue, no persistence modules). **Nothing was merged.**

autonomic-bot changed title from chore: upgrade redis 7.4-alpine -> 8.8-alpine to chore: upgrade app 3.5.3 -> 2026.1.5, redis 7.4-alpine -> 8.8-alpine 2026-07-13 17:59:04 +00:00

autonomic-bot added 1 commit 2026-07-13 17:59:06 +00:00

chore: upgrade app 3.5.3 -> 2026.1.5, redis 7.4-alpine -> 8.8-alpine 0d7519e9ef

autonomic-bot commented 2026-07-13 17:59:20 +00:00

Author

Owner

Copy Link

Copy Source

!testme

!testme

autonomic-bot commented 2026-07-13 18:28:08 +00:00

Author

Owner

Copy Link

Copy Source

!testme

!testme

autonomic-bot commented 2026-07-13 18:30:46 +00:00

Author

Owner

Copy Link

Copy Source

!testme

!testme

autonomic-bot commented 2026-07-13 18:31:12 +00:00

Author

Owner

Copy Link

Copy Source

🌻 cc-ci — testing discourse @ 0d7519e9

⏳ Run in progress — level pending. Live logs.

<!-- cc-ci:testme --> 🌻 **cc-ci** — testing `discourse` @ `0d7519e9` ⏳ Run in progress — level pending. [Live logs](https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1115).

autonomic-bot commented 2026-07-13 19:15:20 +00:00

Author

Owner

Copy Link

Copy Source

!testme

!testme

autonomic-bot commented 2026-07-13 19:15:35 +00:00

Author

Owner

Copy Link

Copy Source

🌻 cc-ci — discourse @ 0d7519e9 ❌ failure

full logs · dashboard

<!-- cc-ci:testme --> 🌻 **cc-ci** — `discourse` @ `0d7519e9` ❌ **failure** [](https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1117) [](https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1117) [full logs](https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1117) · [dashboard](https://ci.commoninternet.net/)

autonomic-bot commented 2026-07-13 20:01:06 +00:00

Author

Owner

Copy Link

Copy Source

!testme RED (build 1117, 2026-07-13) — upgrade is correct; cc-ci upgrade tests are stale for a version bump within the official-image line

The upgrade itself (app 3.5.3 → 2026.1.5, redis 7.4 → 8.8) is correct and verified by direct chaos deploy: app discourse/discourse:2026.1.5 bootstrapped healthy (HTTP 200 on homepage, healthcheck "healthy"), Rails migrations ran automatically on boot (3.5.3 → 2026.1.5 = 239 changes + security patches), redis 8.8 loaded the 7.4 RDB cleanly (BGSAVE OK, 267 keys), db discourse/postgres:pg18 connected and served. No manual migration step needed — the official image handles db:migrate on boot.

The !testme is RED due to two stale cc-ci test issues, not an upgrade regression:

1. test_head_runs_official_image_not_bitnamilegacy hardcodes version 3.5.3

tests/discourse/test_upgrade.py:29 asserts image.startswith("discourse/discourse:3.5.3"). This was correct for the official-image migration PR (bitnami → official 3.5.3), but is stale for any subsequent version bump within the official image line — discourse/discourse:2026.1.5 does not start with discourse/discourse:3.5.3. The assertion should check for the discourse/discourse: prefix (official image, not bitnami), not a specific hardcoded version.

2. Stale "last-green" base (bitnami) causes rollback → sidekiq persists

The cc-ci harness deploys a "dynamic base" (last-green / main tip) and then does a chaos redeploy with the PR head. The last-green base is still bitnamilegacy/discourse:3.5.0 (it has not been updated since the official-image migration merged upstream, because no green run has occurred with the official image yet — a chicken-and-egg). The chaos redeploy from bitnami base → official head fails because the bitnami→official migration requires undeploying first (per release/next WARNING B: "it is necessary to abra app undeploy before deploying this version, otherwise the database will get killed"), which the chaos redeploy does not do. Swarm's failure_action: rollback then reverts the app to the bitnami base, which crash-loops (bitnami cannot connect to discourse/postgres:pg18). This also means test_sidekiq_service_dropped_by_head (test_upgrade.py:35) fails — the bitnami base's sidekiq service persists after the rollback.

What needs to happen (with --with-tests)

• Relax the hardcoded version assertion in test_head_runs_official_image_not_bitnamilegacy to check for the discourse/discourse: prefix instead of discourse/discourse:3.5.3.
• Update the dynamic base to the current upstream main (which uses the official discourse/discourse image), so the chaos redeploy is official→official (not bitnami→official). This may require a one-time base reset or an undeploy step in the harness for the bitnami→official transition.

Re-run /recipe-upgrade discourse --with-tests to open + verify a cc-ci test-update PR that addresses both issues.

Nothing was merged. PR #6 awaits operator review.

## !testme RED (build 1117, 2026-07-13) — upgrade is correct; cc-ci upgrade tests are stale for a version bump within the official-image line The upgrade itself (app 3.5.3 → 2026.1.5, redis 7.4 → 8.8) is **correct and verified by direct chaos deploy**: app `discourse/discourse:2026.1.5` bootstrapped healthy (HTTP 200 on homepage, healthcheck "healthy"), Rails migrations ran automatically on boot (3.5.3 → 2026.1.5 = 239 changes + security patches), redis 8.8 loaded the 7.4 RDB cleanly (BGSAVE OK, 267 keys), db `discourse/postgres:pg18` connected and served. No manual migration step needed — the official image handles `db:migrate` on boot. The `!testme` is RED due to **two stale cc-ci test issues**, not an upgrade regression: ### 1. `test_head_runs_official_image_not_bitnamilegacy` hardcodes version 3.5.3 `tests/discourse/test_upgrade.py:29` asserts `image.startswith("discourse/discourse:3.5.3")`. This was correct for the official-image migration PR (bitnami → official 3.5.3), but is **stale for any subsequent version bump within the official image line** — `discourse/discourse:2026.1.5` does not start with `discourse/discourse:3.5.3`. The assertion should check for the `discourse/discourse:` prefix (official image, not bitnami), not a specific hardcoded version. ### 2. Stale "last-green" base (bitnami) causes rollback → sidekiq persists The cc-ci harness deploys a "dynamic base" (last-green / main tip) and then does a chaos redeploy with the PR head. The last-green base is still `bitnamilegacy/discourse:3.5.0` (it has not been updated since the official-image migration merged upstream, because no green run has occurred with the official image yet — a chicken-and-egg). The chaos redeploy from bitnami base → official head fails because the bitnami→official migration requires **undeploying first** (per `release/next` WARNING B: "it is necessary to `abra app undeploy` before deploying this version, otherwise the database will get killed"), which the chaos redeploy does not do. Swarm's `failure_action: rollback` then reverts the app to the bitnami base, which crash-loops (bitnami cannot connect to `discourse/postgres:pg18`). This also means `test_sidekiq_service_dropped_by_head` (test_upgrade.py:35) fails — the bitnami base's sidekiq service persists after the rollback. ### What needs to happen (with `--with-tests`) - Relax the hardcoded version assertion in `test_head_runs_official_image_not_bitnamilegacy` to check for the `discourse/discourse:` prefix instead of `discourse/discourse:3.5.3`. - Update the dynamic base to the current upstream main (which uses the official `discourse/discourse` image), so the chaos redeploy is official→official (not bitnami→official). This may require a one-time base reset or an undeploy step in the harness for the bitnami→official transition. **Re-run `/recipe-upgrade discourse --with-tests`** to open + verify a cc-ci test-update PR that addresses both issues. **Nothing was merged.** PR #6 awaits operator review.

autonomic-bot changed title from chore: upgrade app 3.5.3 -> 2026.1.5, redis 7.4-alpine -> 8.8-alpine to chore: upgrade app to 2026.7.1, redis to 8.10-alpine 2026-08-03 22:24:22 +00:00

autonomic-bot added 1 commit 2026-08-03 22:24:23 +00:00

chore: upgrade app to 2026.7.1, redis to 8.10-alpine bfa21bc44e

autonomic-bot commented 2026-08-03 22:24:27 +00:00

Author

Owner

Copy Link

Copy Source

!testme

!testme

autonomic-bot commented 2026-08-03 22:44:05 +00:00

Author

Owner

Copy Link

Copy Source

!testme

!testme

autonomic-bot commented 2026-08-03 23:32:40 +00:00

Author

Owner

Copy Link

Copy Source

cc-ci !testme verdict: RED (Drone build #1165) — reported manually (the ccci-bridge container silently dropped the !testme trigger due to its stale gitea-bot swarm secret → HTTP 401; the Drone build was driven directly via the Drone API and the verdict reflected back as this commit-status + comment).

Diagnosis: the upgrade itself is CORRECT — the RED is on a stale cc-ci upgrade-tier base (DEFAULT mode: comment only, tests not touched)

• install tier: PASS — a fresh deploy of the PR head (discourse/discourse:2026.7.1 + redis:8.10-alpine + discourse/postgres:pg18) converged and serves ok on /srv/status. The 2026.1.5 → 2026.7.1 bump itself is sound.
• upgrade tier: FAIL — the cc-ci harness chose the upgrade base as 0.8.1+3.5.0 ("newest release tag older than head 1.0.0+3.5.3"), i.e. the bitnami recipe (app bitnamilegacy/discourse:3.5.0, db pgvector/pgvector:pg17, separate sidekiq service). In-place-upgrading that to the head crosses the 0.8 → 1.0 breaking boundary: the db image family changes from pgvector/pgvector:pg17 to discourse/postgres:pg18 (incompatible on-disk PGDATA layout), so the pg18 container initialises a fresh cluster (FATAL: database "discourse" does not exist), the app can't connect, the new task is SIGTERM'd → graceful exit 0, and swarm's update_config.failure_action=rollback reverts to 3.5.0. This is the unsupported breaking-major path — it has nothing to do with the 2026.1.5 → 2026.7.1 bump (I did not touch the db image).
• The supported in-place upgrade path works. I verified locally (dev-discourse, --chaos): deploy 1.0.0+3.5.3 (official image, already discourse/postgres:pg18), then upgrade to the PR head → the app reconverges to discourse/discourse:2026.7.1, healthy, serving ok, no rollback, data preserved. I.e. official→official in-place upgrade across this PR is green.

Why this is a stale cc-ci test config (not a recipe regression)

The cc-ci upgrade tier's base = newest release tag older than head heuristic picks 0.8.1+3.5.0, but the recipe's 0.8 → 1.0 is a breaking major version boundary (the official-image switch, PR #16) that is not meant to be crossed by an in-place swarm upgrade — it requires a fresh install or a manual pgvector→discourse/postgres dump/restore. The sane in-place upgrade base for the official-image lineage is 1.0.0+3.5.3 (official→official, same db family).

Recommendation (operator)

To turn this PR's !testme green, the cc-ci upgrade-tier base for discourse should be overridden to 1.0.0+3.5.3 (the supported in-place path) instead of the bitnami 0.8.1+3.5.0 boundary cross. That is a cc-ci test/config change — re-run /recipe-upgrade discourse --with-tests to open + verify a cc-ci test PR that does that override. (Per DEFAULT mode, I have NOT modified any cc-ci test/harness.)

— recipe-upgrade (DEFAULT mode), 2026-08-03

**cc-ci `!testme` verdict: RED** (Drone build [#1165](https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1165)) — reported manually (the `ccci-bridge` container silently dropped the `!testme` trigger due to its stale gitea-bot swarm secret → HTTP 401; the Drone build was driven directly via the Drone API and the verdict reflected back as this commit-status + comment). ## Diagnosis: the upgrade itself is CORRECT — the RED is on a stale cc-ci upgrade-tier base (DEFAULT mode: comment only, tests not touched) - **install tier: PASS** — a fresh deploy of the PR head (`discourse/discourse:2026.7.1` + `redis:8.10-alpine` + `discourse/postgres:pg18`) converged and serves `ok` on `/srv/status`. The 2026.1.5 → 2026.7.1 bump itself is sound. - **upgrade tier: FAIL** — the cc-ci harness chose the upgrade base as `0.8.1+3.5.0` ("newest release tag older than head `1.0.0+3.5.3`"), i.e. the **bitnami** recipe (app `bitnamilegacy/discourse:3.5.0`, db `pgvector/pgvector:pg17`, separate `sidekiq` service). In-place-upgrading that to the head crosses the **0.8 → 1.0 breaking boundary**: the db image family changes from `pgvector/pgvector:pg17` to `discourse/postgres:pg18` (incompatible on-disk PGDATA layout), so the pg18 container initialises a **fresh** cluster (`FATAL: database "discourse" does not exist`), the app can't connect, the new task is SIGTERM'd → graceful exit 0, and swarm's `update_config.failure_action=rollback` reverts to 3.5.0. This is the unsupported breaking-major path — it has nothing to do with the `2026.1.5 → 2026.7.1` bump (I did not touch the db image). - **The supported in-place upgrade path works.** I verified locally (`dev-discourse`, `--chaos`): deploy `1.0.0+3.5.3` (official image, already `discourse/postgres:pg18`), then upgrade to the PR head → the app reconverges to `discourse/discourse:2026.7.1`, **healthy, serving `ok`, no rollback**, data preserved. I.e. official→official in-place upgrade across this PR is green. ## Why this is a stale cc-ci test config (not a recipe regression) The cc-ci upgrade tier's `base = newest release tag older than head` heuristic picks `0.8.1+3.5.0`, but the recipe's `0.8 → 1.0` is a **breaking major version boundary** (the official-image switch, PR #16) that is not meant to be crossed by an in-place swarm upgrade — it requires a fresh install or a manual pgvector→discourse/postgres dump/restore. The sane in-place upgrade base for the official-image lineage is `1.0.0+3.5.3` (official→official, same db family). ## Recommendation (operator) To turn this PR's `!testme` green, the cc-ci upgrade-tier base for `discourse` should be overridden to `1.0.0+3.5.3` (the supported in-place path) instead of the bitnami `0.8.1+3.5.0` boundary cross. That is a cc-ci test/config change — re-run **`/recipe-upgrade discourse --with-tests`** to open + verify a cc-ci test PR that does that override. (Per DEFAULT mode, I have NOT modified any cc-ci test/harness.) — `recipe-upgrade` (DEFAULT mode), 2026-08-03

autonomic-bot commented 2026-08-04 00:02:25 +00:00

Author

Owner

Copy Link

Copy Source

!testme result — build #1171 (2026-08-04)

Verdict: the upgrade is correct; the CI upgrade-tier goes RED on a pre-existing bitnami→official DB-role gap that is NOT a regression of this PR.

What was verified GREEN (direct fresh deploy on the cc-ci swarm)

A --chaos deploy of this PR head (discourse/discourse:2026.7.1 + redis:8.10-alpine, db discourse/postgres:pg18 unchanged) under dev-discourse.ci.commoninternet.net converged cleanly: PostgreSQL 18.4 ready, Rails migrations ran on boot, asset precompile done, app healthcheck curl /srv/status → ok (healthy), sidekiq + redis 8.10-alpine ready. The 2026.1→2026.7 ESR jump works for a fresh install. Dev deploy torn down.

What went RED in CI (drone build #1171) and why it is NOT a regression

The harness upgrade tier deploys a previous published release then upgrades in place to the PR head. Because the recipe version label is still 1.0.0+3.5.3 (intentionally not bumped in this PR — the operator bumps it at release time via abra recipe release), the harness selects release 0.8.1+3.5.0 (the bitnami recipe, bitnamilegacy/discourse:3.5.0 + pgvector/pgvector:pg17) as the upgrade base, then chaos-redeploys the PR head (discourse/discourse:2026.7.1 + discourse/postgres:pg18) on top of it.

That bitnami→official jump fails at app boot with:

PG::ConnectionBad: FATAL:  role "discourse" does not exist
ActiveRecord::NoDatabaseError: We could not find your database: discourse

The bitnami DB cluster (bootstrapped by pgvector/pgvector:pg17 with POSTGRES_USER=postgres) has no discourse role, and the official image's app connects as DISCOURSE_DB_USERNAME=discourse. discourse/postgres:pg18 runs pg_upgrade on the existing cluster but does not create the missing discourse role (pg_upgrade preserves existing roles). So the app can't connect.

This is a pre-existing bitnami→official migration gap — the same failure would occur for bitnami→3.5.3 (the current upstream main), so it is not introduced by this PR's 3.5.3→2026.7.1 bump. The bitnami→official path was the subject of the already-merged official-image switch (PR #16); this PR only moves the official image 3.5.3 → 2026.7.1.

Why the CI path is wrong for this PR (and would be GREEN with a released label)

With the version label bumped to reflect 2026.7.1 (e.g. 2.0.0+2026.7.1 after abra recipe release discourse -x), the harness would select 1.0.0+3.5.3 (the official image, discourse/discourse:3.5.3 + discourse/postgres:pg18, which bootstraps the discourse role) as the upgrade base. The 3.5.3 → 2026.7.1 upgrade is the realistic path for this PR and uses the same DB image family on both sides — the discourse role already exists, so the app connects, migrations run, and it converges (as the fresh deploy above confirms).

Operator action

• The image-tag changes in this PR (app 3.5.3→2026.7.1, redis 7.4-alpine→8.10-alpine, db pg18 unchanged) are correct and verified on a fresh install.
• Recommended release: abra recipe release discourse -x (major — ~6-month ESR jump with Unicorn→Pitchfork, default-on behavior changes via Upcoming Changes, and .hbs/.js.es6 theme deprecations). Bumping the label makes the post-release CI test the correct 3.5.3→2026.7.1 upgrade path.
• Existing-site operators should review the 2026.1→2026.7 jump guide (Discourse Reactions on by default, Uncategorized removal, rich_editor setting gone, .hbs deprecation).

NOT merged — for operator review. The cc-ci/testme commit status is set to failure to reflect the upgrade-tier RED; this comment explains why that RED is a stale-path artifact rather than a regression of this PR's bump.

## !testme result — build #1171 (2026-08-04) **Verdict: the upgrade is correct; the CI upgrade-tier goes RED on a pre-existing bitnami→official DB-role gap that is NOT a regression of this PR.** ### What was verified GREEN (direct fresh deploy on the cc-ci swarm) A `--chaos` deploy of this PR head (`discourse/discourse:2026.7.1` + `redis:8.10-alpine`, db `discourse/postgres:pg18` unchanged) under `dev-discourse.ci.commoninternet.net` converged cleanly: PostgreSQL 18.4 ready, Rails migrations ran on boot, asset precompile done, app healthcheck `curl /srv/status` → `ok` (healthy), sidekiq + redis 8.10-alpine ready. The 2026.1→2026.7 ESR jump works for a fresh install. Dev deploy torn down. ### What went RED in CI (drone build #1171) and why it is NOT a regression The harness `upgrade` tier deploys a **previous published release** then upgrades in place to the PR head. Because the recipe version label is still `1.0.0+3.5.3` (intentionally **not** bumped in this PR — the operator bumps it at release time via `abra recipe release`), the harness selects release `0.8.1+3.5.0` (the **bitnami** recipe, `bitnamilegacy/discourse:3.5.0` + `pgvector/pgvector:pg17`) as the upgrade base, then chaos-redeploys the PR head (`discourse/discourse:2026.7.1` + `discourse/postgres:pg18`) on top of it. That bitnami→official jump fails at app boot with: ``` PG::ConnectionBad: FATAL: role "discourse" does not exist ActiveRecord::NoDatabaseError: We could not find your database: discourse ``` The bitnami DB cluster (bootstrapped by `pgvector/pgvector:pg17` with `POSTGRES_USER=postgres`) has no `discourse` role, and the official image's app connects as `DISCOURSE_DB_USERNAME=discourse`. `discourse/postgres:pg18` runs `pg_upgrade` on the existing cluster but does **not** create the missing `discourse` role (pg_upgrade preserves existing roles). So the app can't connect. This is a **pre-existing bitnami→official migration gap** — the same failure would occur for bitnami→`3.5.3` (the current upstream main), so it is **not introduced by this PR's `3.5.3→2026.7.1` bump**. The bitnami→official path was the subject of the already-merged official-image switch (PR #16); this PR only moves the official image `3.5.3 → 2026.7.1`. ### Why the CI path is wrong for this PR (and would be GREEN with a released label) With the version label bumped to reflect `2026.7.1` (e.g. `2.0.0+2026.7.1` after `abra recipe release discourse -x`), the harness would select `1.0.0+3.5.3` (the **official** image, `discourse/discourse:3.5.3` + `discourse/postgres:pg18`, which bootstraps the `discourse` role) as the upgrade base. The `3.5.3 → 2026.7.1` upgrade is the realistic path for this PR and uses the same DB image family on both sides — the `discourse` role already exists, so the app connects, migrations run, and it converges (as the fresh deploy above confirms). ### Operator action - The image-tag changes in this PR (`app` 3.5.3→2026.7.1, `redis` 7.4-alpine→8.10-alpine, `db` pg18 unchanged) are correct and verified on a fresh install. - Recommended release: `abra recipe release discourse -x` (major — ~6-month ESR jump with Unicorn→Pitchfork, default-on behavior changes via Upcoming Changes, and `.hbs`/`.js.es6` theme deprecations). Bumping the label makes the post-release CI test the correct `3.5.3→2026.7.1` upgrade path. - Existing-site operators should review the [2026.1→2026.7 jump guide](https://meta.discourse.org/t/jumping-from-2026-1-esr-to-2026-7-what-i-found/408779) (Discourse Reactions on by default, Uncategorized removal, `rich_editor` setting gone, `.hbs` deprecation). NOT merged — for operator review. The `cc-ci/testme` commit status is set to `failure` to reflect the upgrade-tier RED; this comment explains why that RED is a stale-path artifact rather than a regression of this PR's bump.

autonomic-bot referenced this pull request from recipe-maintainers/cc-ci 2026-08-04 17:15:56 +00:00

test(discourse): UPGRADE_BASE_FLOOR — exclude structurally-invalid upgrade bases #15

autonomic-bot commented 2026-08-04 17:57:46 +00:00

Author

Owner

Copy Link

Copy Source

Stale tests fixed and merged — verdict now GREEN (cc-ci PR #15, cold full-suite level 5/5 against THIS PR's head bfa21bc4).

Two stale-test roots fixed, no assertion weakened:

1. UPGRADE_BASE_FLOOR — the upgrade-tier base resolver no longer steps back across the 0.8→1.0 structural break (bitnami→official db-family change with no supported in-place path). Resolution stays dynamic; discourse declares floor 1.0.0+3.5.3.
2. The upgrade faithfulness test's hardcoded discourse/discourse:3.5.3 pin is now the version-agnostic official-image-family assertion (it guards official-vs-bitnami, not a frozen version).

Status reflected as cc-ci/testme=success on head. Ready for operator review/merge — with keycloak #5 and mailu #6 also green now, all three pending PRs from the 2026-08-03 weekly run are unblocked.

**Stale tests fixed and merged — verdict now GREEN** (cc-ci PR [#15](https://git.autonomic.zone/recipe-maintainers/cc-ci/pulls/15), cold full-suite level 5/5 against THIS PR's head `bfa21bc4`). Two stale-test roots fixed, no assertion weakened: 1. **`UPGRADE_BASE_FLOOR`** — the upgrade-tier base resolver no longer steps back across the 0.8→1.0 structural break (bitnami→official db-family change with no supported in-place path). Resolution stays dynamic; discourse declares floor `1.0.0+3.5.3`. 2. The upgrade faithfulness test's hardcoded `discourse/discourse:3.5.3` pin is now the version-agnostic official-image-family assertion (it guards official-vs-bitnami, not a frozen version). Status reflected as `cc-ci/testme=success` on head. Ready for operator review/merge — with keycloak #5 and mailu #6 also green now, all three pending PRs from the 2026-08-03 weekly run are unblocked.

autonomic-bot commented 2026-08-07 03:00:47 +00:00

Author

Owner

Copy Link

Copy Source

!testme

!testme

autonomic-bot commented 2026-08-07 03:00:55 +00:00

Author

Owner

Copy Link

Copy Source

🌻 cc-ci — discourse @ bfa21bc4 ✅ passed

full logs · dashboard

<!-- cc-ci:testme --> 🌻 **cc-ci** — `discourse` @ `bfa21bc4` ✅ **passed** [](https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1206) [](https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1206) [full logs](https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1206) · [dashboard](https://ci.commoninternet.net/)

autonomic-bot referenced this pull request 2026-08-10 20:25:02 +00:00

fix(image): re-pin bitnami->bitnamilegacy/discourse:3.3.1 (Docker Hub emptied bitnami/discourse) #1

autonomic-bot referenced this pull request 2026-08-10 20:25:03 +00:00

feat(discourse): switch app to official discourse/discourse image (experimental) #5

autonomic-bot referenced this pull request 2026-08-10 20:25:03 +00:00

fix(app): use stack-prefixed hostnames for redis and db #8

autonomic-bot commented 2026-08-10 20:34:30 +00:00

Author

Owner

Copy Link

Copy Source

Reconciled the branch with upstream main.

This PR's file list was showing the official-image migration (migrate-uploads.sh, pg_backup.sh, release/next, …) as if this PR introduced it — 11 files / ~252 insertions. Cause: the branch was cut before coop-cloud/discourse#16 landed, so its merge-base was 0.8.1+3.5.0 and Gitea diffed from there. The branch tree already matched upstream; only its history lacked those commits.

Merging main in records them. The resulting tree is byte-identical to before, and the PR now shows what it actually changes:

image: discourse/discourse:3.5.3   → discourse/discourse:2026.7.1
image: redis:7.4-alpine            → redis:8.10-alpine

(The compose.yml conflict was resolved in favour of the branch — both sides edited the same image lines, and the branch already carried upstream's official-image switch plus these bumps.)

Re-running !testme since the head SHA changed; the tree is unchanged, so the prior verdict still describes this content.

Reconciled the branch with upstream main. This PR's file list was showing the **official-image migration** (`migrate-uploads.sh`, `pg_backup.sh`, `release/next`, …) as if this PR introduced it — 11 files / ~252 insertions. Cause: the branch was cut before coop-cloud/discourse#16 landed, so its merge-base was `0.8.1+3.5.0` and Gitea diffed from there. The branch *tree* already matched upstream; only its history lacked those commits. Merging main in records them. The resulting tree is **byte-identical** to before, and the PR now shows what it actually changes: ``` image: discourse/discourse:3.5.3 → discourse/discourse:2026.7.1 image: redis:7.4-alpine → redis:8.10-alpine ``` (The compose.yml conflict was resolved in favour of the branch — both sides edited the same image lines, and the branch already carried upstream's official-image switch plus these bumps.) Re-running `!testme` since the head SHA changed; the tree is unchanged, so the prior verdict still describes this content.

autonomic-bot commented 2026-08-10 20:34:30 +00:00

Author

Owner

Copy Link

Copy Source

!testme

!testme

autonomic-bot added 1 commit 2026-08-10 20:34:32 +00:00

chore: merge upstream main into the upgrade branch ... f8dcc78013

The branch predated the official-image migration (coop-cloud/discourse#16), so its
merge-base was 0.8.1+3.5.0 and the PR's file list re-showed that migration's changes
as if this PR introduced them. The branch TREE already matched upstream; only its
history lacked those commits. Recording the merge leaves the PR's diff as what it
actually changes: app 3.5.3 -> 2026.7.1 and redis 7.4-alpine -> 8.10-alpine.

Conflict in compose.yml resolved in favour of the branch (both sides edited the same
image lines; the branch already carries upstream's official-image switch plus the
version bumps). Resulting tree is byte-identical to the pre-merge branch tree.

autonomic-bot commented 2026-08-10 20:34:50 +00:00

Author

Owner

Copy Link

Copy Source

🌻 cc-ci — discourse @ f8dcc780 ✅ passed

full logs · dashboard

<!-- cc-ci:testme --> 🌻 **cc-ci** — `discourse` @ `f8dcc780` ✅ **passed** [](https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1235) [](https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1235) [full logs](https://drone.ci.commoninternet.net/recipe-maintainers/cc-ci/1235) · [dashboard](https://ci.commoninternet.net/)

autonomic-bot commented 2026-08-11 19:14:11 +00:00

Author

Owner

Copy Link

Copy Source

Auto-closed by /recipe-upgrade: its changes are already in upstream main (merged upstream); mirror main re-synced

Auto-closed by /recipe-upgrade: its changes are already in upstream main (merged upstream); mirror main re-synced

autonomic-bot closed this pull request 2026-08-11 19:14:11 +00:00

Pull request closed

Please reopen this pull request to perform a merge.

Sign in to join this conversation.

Reviewers

No Reviewers

notplants

trav

Labels

No items

No labels

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

autonomic autonomic-bot kawaiipunk (KawaiiPunk) notplants trav (Trav Fryer)

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: recipe-maintainers/discourse#6