Skip to content

ci: weekly scheduled rebuild of master container images#301

Open
pjordanandrsn wants to merge 1 commit intobrian7704:masterfrom
pjordanandrsn:weekly-rebuild-schedule
Open

ci: weekly scheduled rebuild of master container images#301
pjordanandrsn wants to merge 1 commit intobrian7704:masterfrom
pjordanandrsn:weekly-rebuild-schedule

Conversation

@pjordanandrsn
Copy link
Copy Markdown

Motivation

The four images published by .github/workflows/docker.yml (opentakserver, ots_cot_parser, ots_eud_handler, ots_eud_handler_ssl) currently rebuild only when a new release is published. The :master tags then drift behind upstream Python and Debian security fixes between releases.

A trivy scan of the four :master images on 2026-05-02 (last published 2025-10-17) found:

Image HIGH CRITICAL
ghcr.io/brian7704/ots_eud_handler:master 754 154
ghcr.io/brian7704/ots_eud_handler_ssl:master 754 154
ghcr.io/brian7704/ots_cot_parser:master 0 0 (clean)
ghcr.io/brian7704/opentakserver:master 0 0 (clean)

All eud_handler findings are in OS packages of the python:3.13 base. Rebuilding the same Dockerfile with --pull against a current python:3.13 reduces these to zero — no source changes, no application risk.

Change

Adds a schedule: trigger to the existing Docker Image CI workflow:

on:
  release:
    types: [published]
  workflow_dispatch:
  schedule:
    - cron: '0 4 * * 0'   # Sunday 04:00 UTC

The matrix already builds all four images with --pull semantics via docker/build-push-action@v6, so no other changes are needed. Weekly cadence matches typical Debian/Python base-image refresh cycles without burning excessive CI minutes.

Alternatives considered

  • More frequent (daily): Wasteful given base images don't refresh that often.
  • Less frequent (monthly): Leaves a >30-day window for known-fixed CVEs.
  • Separate workflow: Cleaner but adds a duplicate matrix definition. Inline schedule: reuses what's already there.

Verified locally

Same Dockerfiles built with docker build --pull against current python:3.13:

  • ots_eud_handler → 0 HIGH/CRITICAL OS CVEs
  • ots_eud_handler_ssl → 0 HIGH/CRITICAL OS CVEs

Happy to adjust the cron schedule or split into a separate workflow file if preferred.

Currently the four images published by docker.yml rebuild only when a new
release is published. Between releases the :master tags drift behind on
python:3.13 / debian-bookworm OS-package fixes — a trivy scan of the
2025-10-17 images on 2026-05-02 found 154 CRITICAL + 754 HIGH OS CVEs
in each of ots_eud_handler{,_ssl}.

Adding a 'schedule:' trigger lets the existing matrix run weekly so the
:master tags stay current with base-layer fixes between releases. No
source change, no application risk — same Dockerfiles, fresher base.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant