Ship docker-compose.release.yml and .env.example as release assets#31
Merged
Conversation
The README quickstart points users at 'https://github.com/onemli/fabrik/releases/latest/download/docker-compose.release.yml' and the matching '.env.example', but neither file was ever attached to a release. New installs that followed the README hit a 404. Two changes fix that: 1. docker-compose.release.yml: a standalone release-time compose file that pulls pre-built images from Docker Hub. No build context, no source tree required. The image tag defaults to FABRIK_VERSION or 'latest' if that's not set; CI overrides the default per release. 2. .github/workflows/docker-build.yml: new attach-release-assets job that runs on tag pushes, bakes the tag version into docker-compose.release.yml as the default FABRIK_VERSION, and uploads both docker-compose.release.yml and .env.example to the existing GitHub Release with 'gh release upload --clobber'. The release itself is still created manually beforehand with curated notes. This job only attaches the two files to it.
GitHub release asset storage strips leading dots from filenames and serves dotfiles under a 'default.' prefix, so .env.example uploaded as-is appeared on releases as default.env.example, which broke the README's quickstart curl URL. The workflow now copies .env.example to env.example before upload. The README curl URL drops the leading dot in the asset name but the local filename stays .env.example (the -o flag controls where it lands on disk).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The README's quickstart instructions tell users to download the compose file and a sample env from GitHub Releases:
```bash
curl -fLo docker-compose.yml https://github.com/onemli/fabrik/releases/latest/download/docker-compose.release.yml
curl -fLo .env.example https://github.com/onemli/fabrik/releases/latest/download/.env.example
```
Neither file was ever attached to a release. Anyone following the quickstart hits a 404 on both URLs.
What this PR does
1. `docker-compose.release.yml` (new file in repo root)
A standalone release-time compose file. Same seven services as the dev compose (postgres, redis, neo4j, backend, celery-worker, celery-beat, frontend) but with the `build:` sections removed — it pulls images from Docker Hub instead. The image tag is `${FABRIK_VERSION:-latest}` so users can pin via env var.
Validated:
```
docker compose -f docker-compose.release.yml config # default → :latest
FABRIK_VERSION=1.2.1 docker compose -f docker-compose.release.yml config # pinned → :1.2.1
```
Both resolve cleanly.
2. New `attach-release-assets` job in `docker-build.yml`
Runs only on tag pushes (`refs/tags/v*`), after both image builds finish. Two steps:
a. Bake version into the compose file. Replaces `${FABRIK_VERSION:-latest}` with `${FABRIK_VERSION:-}` via sed. So the file attached to v1.3.7's release defaults to `onemli/fabrik-*:1.3.7` without losing the env-var override path.
b. Upload to release with `gh release upload --clobber`. The release has to already exist (created manually with curated notes); this job just attaches the two files. `--clobber` lets re-runs replace previously-uploaded copies.
Backfill
After merge I will manually upload version-baked copies of `docker-compose.release.yml` plus the current `.env.example` to v1.2.0 and v1.2.1 releases, so existing release pages also work.
Future releases
The workflow takes over from v1.2.2 onward. The release process becomes:
```
git tag v1.2.2
git push origin v1.2.2
gh release create v1.2.2 --title "..." --notes "..."
CI builds images, attaches SBOMs (anchore), attaches compose+env (new job)
```