WhyIsTheDLRShut.Today/README.md

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:

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:

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. 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.

<!-- 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.