Discuss scheduled Dockerfile and Porter bundle build checks

Start by reviewing the draft implementation in #5089 and the linked fork pull request, then inspect its GitHub-script regression tests and workflow behavior. Done means the agreed schedule and pull-request coverage are implemented, selected targets report complete results, failures are detected, and the existing tests, linting, and documentation build pass.

Draft implementation for discussion: #5089.

Problem

The existing Docker build workflow covers five images. Porter bundle images are built during deployment validation, which requires a maintainer-triggered run. External package failures can remain undetected until deployment, as reported in #5083.

Proposal

Add a workflow that builds the repository's Dockerfiles and Porter bundle images:

• Weekly and on manual request, build every tracked target.
• On pull requests, build selected targets and include bundles affected by shared Porter toolchain and build-helper changes.
• Report every selected target, including failures and missing results.

Use GitHub-hosted runners with read-only repository permissions. Reuse the repository's Porter version pins and build helper. Do not require Azure deployment credentials or publish images.

Existing evidence

The fork draft has a run with 33 build targets: 32 passed, and OHDSI failed with the Bullseye package-download 404s described in #5083. All 33 result artifacts were uploaded and the report correctly failed for OHDSI.

The draft now includes shared-input selection, complete result checks and regression tests. All 124 GitHub-script tests pass locally and in CI, along with linting and the strict documentation build.

This proposal detects build failures. The OHDSI package fix remains separate.

For discussion

I am opening a draft PR alongside this proposal so the implementation can be reviewed. This is for discussion before deciding whether to adopt the workflow.

• Does the weekly schedule, manual trigger and selected pull request coverage fit the project's CI expectations?
• Should scheduled build failures also create or update a GitHub issue, or are the checks and run summaries sufficient?

Automatic issue creation is not implemented in the draft. If wanted, a separate scheduled reporting job could maintain one tracking issue and update it when the failure set changes. That job would need issues: write; build jobs would remain read-only. Pull request runs would use their existing checks. Serialised updates and a stable issue marker would avoid duplicate issues from repeated runs.