Problem
The default openemr/openemr:flex tag is published only on manual workflow_dispatch runs of .github/workflows/build-323.yml (which currently builds the Alpine 3.23 / PHP 8.5 default flex image).
Nothing automatic refreshes it when commits land on either openemr-devops@master or openemr/openemr@master. As a result, fixes can sit unpublished for weeks and docker pull openemr/openemr:flex returns a stale image.
A concrete recent example: fix(flex): use sql_upgrade.php CLI mode in upgradeOpenEMR (#666) merged on 2026-05-01, but as of today the published openemr/openemr:flex digest is still the 2026-04-07 build, so openemr-cmd dev-reset-install-demodata continues to fail in a fresh container until the workflow is dispatched manually.
Why this matters
The flex image is the development image users get from docker/development-easy/docker-compose.yml upstream. When devops fixes don't reach it, every developer running openemr-cmd drid (or anything else that exercises the bundled devtoolsLibrary.source) hits the old bug — even with a fully up-to-date openemr/openemr checkout, since the image bakes both repos' contents.
Suggested direction
Add a schedule trigger (and keep workflow_dispatch) to .github/workflows/build-323.yml, mirroring the pattern already in use for build-edge.yml:
on:
workflow_dispatch:
schedule:
- cron: '0 2 * * *'A nightly rebuild keeps the flex floating tag within ~24h of the latest devops + openemr master, at the cost of one extra image build per day (and modest registry churn).
If preferred, a workflow_run / repository_dispatch trigger from the openemr/openemr master branch is also viable, but cron is simpler and matches the existing edge-build precedent.
When a future Alpine version becomes the new default, the same pattern should move with it (whichever workflow holds is_default_flex: true).
Problem
The default
openemr/openemr:flextag is published only on manualworkflow_dispatchruns of.github/workflows/build-323.yml(which currently builds the Alpine 3.23 / PHP 8.5 default flex image).Nothing automatic refreshes it when commits land on either
openemr-devops@masteroropenemr/openemr@master. As a result, fixes can sit unpublished for weeks anddocker pull openemr/openemr:flexreturns a stale image.A concrete recent example:
fix(flex): use sql_upgrade.php CLI mode in upgradeOpenEMR(#666) merged on 2026-05-01, but as of today the publishedopenemr/openemr:flexdigest is still the 2026-04-07 build, soopenemr-cmd dev-reset-install-demodatacontinues to fail in a fresh container until the workflow is dispatched manually.Why this matters
The flex image is the development image users get from
docker/development-easy/docker-compose.ymlupstream. When devops fixes don't reach it, every developer runningopenemr-cmd drid(or anything else that exercises the bundleddevtoolsLibrary.source) hits the old bug — even with a fully up-to-dateopenemr/openemrcheckout, since the image bakes both repos' contents.Suggested direction
Add a
scheduletrigger (and keepworkflow_dispatch) to.github/workflows/build-323.yml, mirroring the pattern already in use forbuild-edge.yml:A nightly rebuild keeps the
flexfloating tag within ~24h of the latest devops + openemr master, at the cost of one extra image build per day (and modest registry churn).If preferred, a
workflow_run/repository_dispatchtrigger from the openemr/openemr master branch is also viable, but cron is simpler and matches the existing edge-build precedent.When a future Alpine version becomes the new default, the same pattern should move with it (whichever workflow holds
is_default_flex: true).