Emma Thorpe
99084cc597
Build and publish container / build (pull_request) Successful in 2m58s
On each push to main, derive the next semantic version from the conventional-commit messages since the last v* tag (feat -> minor, fix/perf -> patch, \! or BREAKING CHANGE -> major) and, when a release is warranted, build and publish the image tagged X.Y.Z, X.Y, X and latest, then record an annotated vX.Y.Z tag for the next computation. Non-release pushes publish a sha-<short> image only. Configure Renovate to commit updates as fix(deps): so each merged Renovate PR registers as a patch change and is released and tagged automatically. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
113 lines
4.5 KiB
Markdown
113 lines
4.5 KiB
Markdown
# Why is the DLR shut today?
|
|
|
|
A single-page site that displays one randomly chosen message in the centre of
|
|
the screen. The message changes on every page load and whenever the
|
|
**Check again** button is pressed.
|
|
|
|
The site is themed around the Docklands Light Railway colour scheme, with a
|
|
toggle between:
|
|
|
|
- **Modern colours** — the current DLR turquoise/teal branding.
|
|
- **Original colours** — the 1987 DLR red-and-blue livery.
|
|
|
|
The chosen theme is remembered between visits via `localStorage`.
|
|
|
|
## Adding messages
|
|
|
|
Edit `messages.js` and fill the `MESSAGES` array with your own reasons — one
|
|
string per entry. Entries are inserted as plain text. Until you add some, the
|
|
page shows a fallback prompt.
|
|
|
|
## Running
|
|
|
|
It is a static site with no build step. Open `index.html` in a browser, or
|
|
serve the directory with any static file server, for example:
|
|
|
|
```sh
|
|
python3 -m http.server
|
|
```
|
|
|
|
## Container
|
|
|
|
The site is packaged as a container based on `nginxinc/nginx-unprivileged`. It
|
|
runs as a non-root user and listens on port **8080**, serving the static files
|
|
and exposing a `/healthz` endpoint. It is designed to sit behind an external
|
|
reverse proxy that terminates TLS and routes by host.
|
|
|
|
Build and run locally:
|
|
|
|
```sh
|
|
docker build -t dlr .
|
|
docker run --rm -p 8080:8080 dlr
|
|
# then browse http://localhost:8080
|
|
```
|
|
|
|
## CI
|
|
|
|
`.gitea/workflows/build-and-publish.yml` builds the container with Gitea Actions
|
|
on every push to `main` and on pull requests. Pull requests build the image but
|
|
do not push. The registry host is derived from the Gitea server URL.
|
|
|
|
Authentication requires a Personal Access Token with package read/write scope,
|
|
because the automatically provided `GITEA_TOKEN` does not carry container
|
|
registry write permission on most Gitea instances. Create the token under an
|
|
account with write access to the target package namespace, then store it as a
|
|
repository Actions secret named `PACKAGES_TOKEN`.
|
|
|
|
### Automatic releases
|
|
|
|
The published image is `<gitea-host>/<owner>/<repo>`. Releases are derived from
|
|
[Conventional Commits](https://www.conventionalcommits.org/). On each push to
|
|
`main`, the workflow inspects the commits since the last `v*` tag and computes
|
|
the next version:
|
|
|
|
- `feat:` → minor bump,
|
|
- `fix:` / `perf:` → patch bump,
|
|
- `!` or `BREAKING CHANGE` → major bump,
|
|
- anything else (`chore`, `ci`, `docs`, `build`) → no release.
|
|
|
|
When a release is warranted, the image is published with `X.Y.Z`, `X.Y`, `X` and
|
|
`latest` tags, and the workflow records an annotated `vX.Y.Z` git tag so the next
|
|
release is computed from it. Pushes to `main` that warrant no release are
|
|
published under a `sha-<short>` tag only, so `latest` always points at the most
|
|
recent release rather than the newest commit.
|
|
|
|
Recording the release tag requires the workflow's `contents: write` permission;
|
|
if the instance forbids the automatic token from pushing, supply a PAT with
|
|
repository write scope and push the tag with it instead.
|
|
|
|
## Dependency updates
|
|
|
|
`renovate.json` configures Renovate to keep dependencies current:
|
|
|
|
- the Dockerfile base image,
|
|
- the actions used in the Gitea workflow,
|
|
- versioned front-end dependencies referenced in HTML.
|
|
|
|
There are currently no external front-end dependencies. When one is added via a
|
|
CDN, Renovate will track it if it is either annotated with a comment, e.g.
|
|
|
|
```html
|
|
<!-- renovate: datasource=npm depName=bootstrap -->
|
|
<link href="https://cdn.example.com/bootstrap@5.3.3/dist/css/bootstrap.min.css" rel="stylesheet">
|
|
```
|
|
|
|
or referenced through a versioned jsDelivr / unpkg npm URL, which is detected
|
|
automatically.
|
|
|
|
Renovate is configured to commit updates as `fix(deps): …`. Each merged Renovate
|
|
PR therefore registers as a patch-level change, so the release workflow above
|
|
cuts a new patch release and tags the image automatically.
|
|
|
|
## Files
|
|
|
|
| File | Purpose |
|
|
| ------------------------------------- | ------------------------------------------------ |
|
|
| `index.html` | Page structure. |
|
|
| `styles.css` | Both colour schemes, selected via `data-theme`. |
|
|
| `messages.js` | The list of messages (fill this in). |
|
|
| `script.js` | Random message selection and the theme toggle. |
|
|
| `Dockerfile` / `default.conf` | Container image and nginx static-serving config. |
|
|
| `.gitea/workflows/` | Gitea Actions build-and-publish pipeline. |
|
|
| `renovate.json` | Renovate dependency-update configuration. |
|