Automatic updates

PHP releases

A scheduled workflow, .github/workflows/php-version-bump.yml, runs every four hours and executes alpine/check-php-versions.sh --update.

The script downloads the package indexes of every repository the images install from (the base image's Alpine release branch plus edge main, community and testing) for x86_64 and aarch64, takes the newest php8x version across them exactly as apk would, and compares it with the pin in php-versions.txt. When a newer release is present on both architectures it rewrites the pin. The workflow then commits the change to main and dispatches the build workflow, which publishes the new exact tag and moves the minor tag.

PHP 8.2: pinned 8.2.34, Alpine 8.2.34, php.net 8.2.35 (security release, waiting on Alpine)
PHP 8.3: pinned 8.3.35, Alpine 8.3.35, php.net 8.3.36 (security release, waiting on Alpine)
PHP 8.4: pinned 8.4.26, Alpine 8.4.26, php.net 8.4.27 (security release, waiting on Alpine)
PHP 8.5: pinned 8.5.11, Alpine 8.5.11, php.net 8.5.12 (security release, waiting on Alpine)
PHP 8.6: pinned 8.6.0_rc3, Alpine 8.6.0_rc3, php.net: no stable release yet
All pinned PHP releases match Alpine
4 upstream php.net release(s) not yet packaged in Alpine; the pins will follow once they are

The php.net column is informational. Only Alpine availability drives a bump, because pinning a release that apk cannot install just breaks the build. The "security release" wording comes from php.net's own release tags, and "lookup failed" means php.net could not be reached on that run.

Pre-releases

Alpine spells release candidates with an underscore (8.6.0_rc3) while PHP reports 8.6.0RC3. The build normalises both before asserting the installed version, and the check treats a final release as newer than any pre-release of the same base, so 8.6 moves to 8.6.0 automatically when it lands.

Running it yourself

alpine/check-php-versions.sh             # report only
alpine/check-php-versions.sh --update    # rewrite php-versions.txt

The workflow can also be started from the Actions tab with "Run workflow".

Alpine base and GitHub Actions

Dependabot watches two ecosystems weekly:

• docker for alpine/base, so the digest-pinned alpine:3.24@sha256:... line gets a PR when Alpine publishes a new image.
• github-actions, so every pinned action SHA gets a PR when a new release is tagged.

Those PRs run the full pipeline before merge like any other change.

System packages

The weekly rebuild described on Release pipeline republishes every tag with apk upgrade applied, so Alpine security fixes that do not involve PHP still ship within a week, and immediately if anything else triggers a build.