You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat(ci): render Docker Hub readme from versions.yml at build time (#715)
Fixes#709
#### Short description of what this resolves:
Step 15 of the release runbook — updating the Docker Hub readme on
https://hub.docker.com/r/openemr/openemr — was manual: maintainers
edited `docker/openemr/OVERVIEW.md` by hand, then a workflow propagated
it to Docker Hub. This PR removes that manual step. The readme is now
rendered from `tools/release/versions.yml` (the same registry the slot
rotation workflow already uses) and pushed by each production build
workflow after a successful image push.
#### Changes proposed in this pull request:
- New Twig template `tools/release/templates/dockerhub-overview.md.twig`
(renamed from `docker/openemr/OVERVIEW.md`, with version-dependent
values parameterized on slot scalars).
- New renderer `OpenEMR\Release\DockerHubOverviewRenderer`
(`tools/release/src/`) with a thin Symfony Console wrapper at
`tools/release/bin/render-dockerhub-overview.php` and a
`release:render-dockerhub-overview` Task entry. Unit tests cover slot
interpolation, determinism, and error paths.
- New composite action `.github/actions/push-dockerhub-readme` that
checks out, renders, then calls `peter-evans/dockerhub-description@v5`.
- Build workflows `build-704`, `build-800`, `build-810`, `build-811`
call the composite action as their final step (last-writer-wins is
benign because renders are deterministic).
- Retire `.github/workflows/dockerhub-description.yml` and the
hand-edited `docker/openemr/OVERVIEW.md`. Drop the corresponding entry
from `tools/release/versions.yml`.
- Drop the per-build dated tags (e.g. `8.0.0.3-2026-03-25`) from the
readme — they're an immutable-naming mechanism for pinning, not
date-display, and Docker Hub's Tags page already lists them. Replaced
with one sentence explaining the scheme.
#### Notes
- Blocked on the Docker Hub credential rotation in #714 — the previous
workflow has been failing with `Forbidden` on its last two runs. The new
push uses the same `DOCKERHUB_USERNAME` / `DOCKERHUB_TOKEN` secrets, so
the same fix unblocks both.
- Flex tracks (`build-322`, `build-323`, `build-edge`,
`build-flex-core`) are intentionally not wired up — they aren't in the
rotation registry and their portion of the readme is hand-curated. Easy
follow-up if/when they join the rotation.
- Follow-up on `openemr/openemr` to remove step 15 from
`docs/RELEASE_PROCESS.md`'s release runbook.
#### Test plan
- `composer check` clean in `tools/release/` (phpcs, phpstan, rector
dry-run, require-checker, phpunit — 83 tests).
- `actionlint` clean on the four modified build workflows.
- Local render of the template against the real `versions.yml` produces
the expected markdown.
- End-to-end push verifiable once #714 lands: workflow_dispatch on
`build-800.yml` from a topic branch and confirm the Docker Hub readme
reflects the rendered output.
Copy file name to clipboardExpand all lines: tools/release/templates/dockerhub-overview.md.twig
+8-6Lines changed: 8 additions & 6 deletions
Original file line number
Diff line number
Diff line change
@@ -1,13 +1,13 @@
1
1
[OpenEMR](https://www.open-emr.org) is the most popular open source electronic health records and medical practice management solution. OpenEMR's goal is a superior alternative to its proprietary counterparts. With passionate volunteers and contributors dedicated to guarding OpenEMR's status as a free, open source software solution for medical practices with a commitment to openness, kindness and cooperation.
2
2
3
-
**Current production OpenEMR version is 8.0.0**
3
+
**Current production OpenEMR version is {{ current.full }}**
Each production build also pushes an immutable `X.Y.Z-YYYY-MM-DD` tag (e.g. `{{ current.patch }}-2026-03-25`) so a deployment can pin a specific build and survive future rebuilds of the same version. See the [Tags page](https://hub.docker.com/r/openemr/openemr/tags) for the most recent dated tag of each track.
22
+
21
23
This [OpenEMR](http://www.open-emr.org) official docker supports automated installation/configuration of OpenEMR. It requires a companion mysql/mariadb container to work.
22
24
23
25
* Required environment settings for auto installation are `MYSQL_HOST` and `MYSQL_ROOT_PASS`
@@ -36,4 +38,4 @@ This [OpenEMR](http://www.open-emr.org) official docker supports automated insta
36
38
* Can turn on kubernetes/orchestration/swarm/replication support with the `SWARM_MODE` (set it to 'yes'). This only works for the `5.0.2+` and `flex*` images on Docker Swarm and can see [docker-compose.yml](https://gist.github.com/bradymiller/980086836af187285bf28b8db9eecabc) for an example of use in Docker Swarm. This only works for the `6.0.0+` and `flex*` images on Kubernetes and can see [README.md](https://github.com/openemr/openemr-devops/tree/master/kubernetes) for examples of use in Kubernetes. Note the shared volumes /var/www/localhost/htdocs/openemr/sites, /etc/ssl and /etc/letsencrypt are needed in this mode.
37
39
* Can force database SSL or X509 connection by setting one of the following parameters to "1", `FORCE_DATABASE_SSL_CONNECT` or `FORCE_DATABASE_X509_CONNECT`. (ensure you have the SSL or X509 properly configured in the database). This is supported in `7.0.1`+ and flex (`3.15-8`, `edge`, `3.17`+) series.
38
40
* The `flex*` images (`flex-3.22` is Alpine 3.22, `flex-edge` is Alpine Edge, etc.) are for testers and developers and allows use of a OpenEMR version from the specified git repository. Required environment settings for these images are `FLEX_REPOSITORY` and (`FLEX_REPOSITORY_BRANCH` or `FLEX_REPOSITORY_TAG`). `FLEX_REPOSITORY` is the public git repository holding the openemr version that will be used. And `FLEX_REPOSITORY_BRANCH` or `FLEX_REPOSITORY_TAG` represent the branch or tag to use in this git repository, respectively. An exception to the above required settings for these images is if the user sets `EMPTY` environment setting to 'yes'; then these images will not install any openemr in it (this gives a developer flexibility to set up shared volume(s) from host). Another special flag in the `flex*` docker series is `FORCE_NO_BUILD_MODE`, which will force the docker to not build openemr dependent packages/assets via composer/npm if it is set to 'yes'. Two other special flags in the `flex*` docker series is `EASY_DEV_MODE` and `EASY_DEV_MODE_NEW`, which allows use of the "easy development environment" if they are set to 'yes'. Another special flag in the `flex*` docker series is `INSANE_DEV_MODE`, which allows use of devtools in the "insane development environment" if it is set to 'yes'. Another special flag in the `flex*` docker series is `DEVELOPER_TOOLS`, which installs developer/testing tools/packages. Yet another special flag in the `flex*` docker series is `GITHUB_COMPOSER_TOKEN`, which is used to place a github auth token. Another set of special flags in the `flex*` docker series are `XDEBUG_ON`, which will turn on support for xdebug when set to 1 and `XDEBUG_PROFILER_ON`, which will turn on support for xdebug profiling when set to `1` (optional setting for xdebug support are `XDEBUG_IDE_KEY`, `XDEBUG_CLIENT_HOST` and `XDEBUG_CLIENT_PORT`). Another special setting in the `flex*` docker series is `DEMO_MODE`, which when set to `standard`, will load in standard demo data. Another special setting in the `flex*` docker series is `SQL_DATA_DRIVE`, which can be set to a path in the docker; all of the *.sql in this path will be loaded into the OpenEMR database.
39
-
* Automatic upgrading of OpenEMR is supported when upgrade from `5.0.1` to most recent production image tag (for example `8.0.0`) (note this is not supported in the `flex*` series). In your docker-compose.yml file, you can basically change the image version tag (such as `5.0.1`) to the most recent production image version tag (for example `8.0.0`) and then do a `docker-compose up`. Note it will not work for patch version upgrades (ie. `7.0.3` to `7.0.3.4` will not work). Also noted this will only work if you have set a shared volume for the `/var/www/localhost/htdocs/openemr/sites` directory (it will not work if either you didn't set a shared volume or you set the shared volume to be the entire `/var/www/localhost/htdocs/openemr` directory). Before you do this, recommend backing everything up.
41
+
* Automatic upgrading of OpenEMR is supported when upgrade from `5.0.1` to most recent production image tag (for example `{{ current.full }}`) (note this is not supported in the `flex*` series). In your docker-compose.yml file, you can basically change the image version tag (such as `5.0.1`) to the most recent production image version tag (for example `{{ current.full }}`) and then do a `docker-compose up`. Note it will not work for patch version upgrades (ie. `7.0.3` to `7.0.3.4` will not work). Also noted this will only work if you have set a shared volume for the `/var/www/localhost/htdocs/openemr/sites` directory (it will not work if either you didn't set a shared volume or you set the shared volume to be the entire `/var/www/localhost/htdocs/openemr` directory). Before you do this, recommend backing everything up.
0 commit comments