Implement a prefix-based concurrency group to ensure GitHub Merge Queue
events are not prematurely cancelled by simultaneous push events.
- Use 'mq-' prefix in concurrency keys for merge_group events to create
isolated groups distinct from standard push events.
- Maintain PR number in keys to allow synchronize events to cancel
stale runs, preserving CI efficiency.
- Simplify job filters to skip redundant push runs on internal merge
queue branches.
When a PR enters the merge queue, GitHub triggers both a 'merge_group'
and a 'push' event. These events might share the same concurrency key
as they both reference the temporary 'gh-readonly-queue/' branch.
This creates a race condition where the redundant 'push' job could
incorrectly cancel the official 'merge_group' run. This commit adds
an explicit filter to ignore 'push' events on queue branches,
ensuring CI stability and saving runner minutes.
* Updates docker.yml to set the build context to the
local directory.
* This prevents "ref not found" errors when the
workflow runs on temporary branches generated by
the GitHub Merge Queue.
* Ensures the Docker builder utilizes the files
already present in the runner's workspace from
the checkout step.
- Add merge_group event to oxipng.yml and docker.yml for native
Merge Queue support.
- Implement concurrency groups with cancel-in-progress: true to
terminate obsolete builds on new pushes.
- Remove explicit pull_request types to allow default triggers
(including reopened).
Fix#610
- [x] Native cross-compilation support in Dockerfile. Only `linux/amd64`
and `linux/arm64` supported and tested (Tier 1 platform support from
Rust)
- [x] Cache support for cargo downloads and compilation results in
Dockerfile
- [x] Open Container's
[annotations](https://github.com/opencontainers/image-spec/blob/main/annotations.md)
in Dockerfile
- [x] GitHub Actions workflow to build the image for both platforms,
publishing to ghcr.io on tags and master branch pushes.
- [x] Disable use of GitHub Actions cache for tags build, allow manually
triggering the workflow with or without cache.
- [x] [Attestation
artifacts](https://docs.github.com/en/actions/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds)
for builds
- [x] Add basic informations about the use of the Docker image in README
I also changed the WORKDIR from `/src` to `/work`, because if got me
confused with the use of the src folder for the project source in the
first stage of the Dockerfile. It doesn't impact anything anyways since
you can mount the file where you want and have the program options point
to it.
**How to test?**
_After checking out the branch and making sure you have QEMU installed
to build/test_
```shell
# Docker sadly doesn't have yet the way to have locally a tag with multiple platforms
# despite being able to pass multiple platforms to the build command, so we have to use two distinct tags.
docker build --platform=linux/amd64 --tag test-oxipng-amd:latest --load .
docker build --platform=linux/arm64 --tag test-oxipng-arm:latest --load .
docker run --rm test-oxipng-amd:latest --version
docker run --rm test-oxipng-arm:latest --version
# Run on some files
docker run --rm -it -v $(pwd):/work test-oxipng-amd:latest -a /work/tests/files/apng_file.png
docker run --rm -it -v $(pwd):/work test-oxipng-arm:latest -a /work/tests/files/apng_file.png
# Remove the images
docker image rm test-oxipng-amd:latest
docker image rm test-oxipng-arm:latest
```
For the workflow, see the GitHub Actions logs. If you want to test the
ghcr.io publishing you can merge the branch into a fork and see the
result.
---------
Co-authored-by: Alejandro González <me@alegon.dev>
