You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ci: fetch latest versions at runtime; run weekly or on demand
Replace pinned TIMESCALE_VERSION / TIMESCALE_TOOLKIT_VERSION env vars and
the postgres_version / cnpg_version matrix with a runtime resolver:
- TimescaleDB + Toolkit: GitHub releases/latest
- PostgreSQL (CNPG): ghcr.io tags/list filtered to ^16\.[0-9]+$, sort -V
Add schedule (Sun 00:00 UTC) and workflow_dispatch triggers so the image
can be rebuilt against upstream without a PR to bump pins. Push is still
gated to main; branch pushes remain validation-only.
Add CLAUDE.md documenting the resolver, build contract, triggers, and
tag scheme.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
4
+
5
+
## What this repo is
6
+
7
+
A Dockerfile + GitHub Actions pipeline that layers TimescaleDB and TimescaleDB Toolkit onto the upstream `ghcr.io/cloudnative-pg/postgresql` image and publishes it to `ghcr.io/clevyr/cloudnativepg-timescale`. There is no application code, no tests, and no local build scripts — the source of truth is the workflow.
8
+
9
+
## How versions are resolved
10
+
11
+
Versions are **not pinned** in this repo. The `Resolve latest versions` step in `.github/workflows/build.yaml` fetches them at build time:
12
+
13
+
- TimescaleDB + Toolkit: GitHub `releases/latest` of `timescale/timescaledb` and `timescale/timescaledb-toolkit` (leading `v` stripped).
14
+
- PostgreSQL / CNPG: `ghcr.io/v2/cloudnative-pg/postgresql/tags/list`, filtered to `^16\.[0-9]+$` and `sort -V | tail -1`. Only Postgres 16 is tracked — to add another major, add a parallel filter or matrix, don't change `16` in place.
15
+
16
+
`POSTGRES_VERSION` and `CLOUDNATIVEPG_VERSION` are fed the **same** resolved value (the CNPG tag like `16.11`). The Dockerfile uses `$POSTGRES_VERSION` inside the Timescale apt package name, so this relies on Timescale's Debian repo accepting the full `major.minor` (or on apt's loose matching for the major). If a scheduled build starts failing on `apt-get install` of `timescaledb-2-postgresql-<ver>`, verify the packagecloud triplet first — upstream may not have published yet for a brand-new CNPG minor.
17
+
18
+
Renovate (`renovate.json`) no longer drives these versions; its regex managers now match nothing in `build.yaml` but are left in place for future use. Don't reintroduce the old Renovate comment pragmas — they'd fight the runtime resolver.
19
+
20
+
## Build cadence and triggers
21
+
22
+
`build.yaml` runs on `push`, on `workflow_dispatch` (manual), and weekly via `schedule: '0 0 * * 0'` (Sun 00:00 UTC). Only runs on `main` actually push images (`push: ${{ github.ref_name == 'main' }}`); branch pushes are validation-only. Because versions resolve at runtime, two runs minutes apart can produce different images if upstream cut a release in between — that's intentional.
23
+
24
+
## Build contract
25
+
26
+
`Dockerfile` consumes four build args: `CLOUDNATIVEPG_VERSION`, `POSTGRES_VERSION`, `TIMESCALE_VERSION`, `TIMESCALE_TOOLKIT_VERSION`. It installs `timescaledb-2-postgresql-$POSTGRES_VERSION=$TIMESCALE_VERSION~debian$VERSION_ID` and the Toolkit as `=1:$TIMESCALE_TOOLKIT_VERSION~debian$VERSION_ID`, so upstream has to have published a matching `~debianNN` package before a build will succeed.
27
+
28
+
The image ends with `USER 26` (the `postgres` user id CNPG expects). Do not add layers after that as root without resetting the user.
29
+
30
+
## Tag scheme
31
+
32
+
`docker/metadata-action` emits seven tags per build, in priority order: `latest`, `<pg>-ts<ts>` (full), `<pg-minor>-ts<ts-minor>`, `<pg-major>-ts<ts-major>`, then the same three without the `-ts…` suffix. The README example `16-ts2` is the major/major form. Toolkit version does not appear in any tag.
33
+
34
+
## Local iteration
35
+
36
+
`docker build --build-arg ...` against the four args above; no scheduled/remote infra needed. Branches are safe to experiment on — pushes are gated to `main`.
0 commit comments