Check daily for libheif and libde265 releases

[jakejackson1]

Adds a scheduled workflow that opens a pull request when libheif or libde265 publishes a new release, so the fork keeps up with upstream security fixes without anyone watching for them.

Changes

One versions file: scripts/libheif-versions.env pins LIBHEIF_VERSION, LIBDE265_VERSION and EMSDK_VERSION. Before this, the versions were written in build-libheif.sh, the workflow and the README. Now build-libheif.sh, smoke-test.cjs and Build libheif all read the file, and environment variables or workflow inputs still override it.

Build libheif (build-libheif.yml)

• Builds the pinned versions by default.
• The byte-match check now runs whenever the pinned versions are built: on pull requests, and on a manual run without overrides. That's what lets the updater put the check on its own PRs.
• A manual run with overrides skips the check and uploads the rebuilt files, as before.

Check for libheif releases (update-libheif.yml, daily at 06:17 UTC, or run manually)

1. scripts/check-libheif-releases.sh compares the pinned versions with the latest stable releases, using sort -V so it never downgrades. If either is newer, it rewrites the versions file and the README's version line. The Emscripten version follows EMSCRIPTEN_VERSION in libheif's own emscripten.yml at the new tag.
2. It skips a version pair that already has a PR in any state (a closed one means someone decided against it) or an open build-failure issue. A daily run never duplicates work or rebuilds a version that's known to fail.
3. It builds, bundles and smoke-tests. On success it commits src/lib, dist, the versions file and the README to libheif/<libheif>-libde265-<libde265> and opens a PR with release-note links. It then dispatches Build libheif on that branch: a PR opened with GITHUB_TOKEN doesn't trigger pull_request workflows, but a dispatched run does start, and its result shows on the head commit.
4. If the build fails, it opens a Build failed: libheif vX with libde265 vY issue linking the run. Closing the issue lets the next run retry.

Slack: when it opens a PR, and when the run fails (linking the failure issue if one was opened), it posts to Slack through an incoming webhook, like Image Hopper's update-dependencies.yml. SLACK_WEBHOOK_URL is a repository secret on image-hopper, not an org secret, so the fork can't use it yet. Add it with gh secret set SLACK_WEBHOOK_URL -R GravityPDF/heic-to. Until then both Slack steps are skipped.

Otherwise uses only GITHUB_TOKEN. The repo already allows Actions to create PRs, and I enabled Issues on the fork for the failure reports.

Testing

• Locally: the check script returns "up to date" today (1.23.4 / 1.1.3). With the pins faked to 1.23.3 / 1.1.2 it detects both releases, resolves Emscripten 3.1.61 from libheif's CI file and rewrites the versions file and README line. A pin newer than the latest release (1.24.0 / 1.1.10) isn't downgraded. gh pr list --head … --state all finds the merged Upgrade to libheif v1.23.4 and libde265 v1.1.3, built from source #1 branch.
• actionlint passes; the only suppression is SC2016, for Markdown backticks inside a single-quoted string.
• This PR's run exercises the reworked Build libheif (versions from the file, the gate on).
• After merging (a manually triggered workflow has to exist on the default branch): run the updater manually from a throwaway branch whose pins are one release behind. That exercises the full path — build, PR against that branch, dispatched check. Then close it and delete the branch.

🤖 Generated with Claude Code