sillsdev / sillsdev/python-sil-lift
Publish the sil-lift container image to GHCR
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 1
- Forks
- 0
- Avg merge
- 10d 11h
- Merged PRs (30d)
- 6
Description
Background
The repo ships a Dockerfile, a Docker-based GitHub Action (action.yml), and a build-only CI check (.github/workflows/container.yml) so non-Python CI can run sil-lift validate — but no image is published. Consumers must build it themselves, the Action rebuilds the Dockerfile on every run, and there's no docker run ghcr.io/… path.
Proposal
Publish a versioned image to GitHub Container Registry (ghcr.io/sillsdev/python-sil-lift):
- Add a publish job (extend
container.yml, or a newrelease-triggered workflow) that builds and pushes to GHCR usingGITHUB_TOKENwithpermissions: packages: write. - Tags:
vX.Y.Zplus a movinglateston each GitHub Release; optionally anedge/shatag on pushes tomainfor interim testing. - Keep the existing build + smoke-test check on PRs; don't push from PRs/forks.
Docs
- Update the Producing conformant LIFT guide (
docs/en/guides/lift-export-interop.md) to show the pull path —docker run --rm -v "$PWD:/work" -w /work ghcr.io/sillsdev/python-sil-lift validate export.lift --strict— alongside the current build-from-Dockerfile example.
Optional follow-ons
- Point the Action at the published image (
runs.image: docker://ghcr.io/sillsdev/python-sil-lift:<tag>) instead ofDockerfile, souses: sillsdev/python-sil-lift@vXdoesn't rebuild each run (do this together with the release tagging so the tags line up). - Multi-arch build (linux/amd64 + arm64) via buildx/QEMU, if arm runners matter.
Non-goals
- No change to CLI/validate behavior or image contents.
- PyPI publishing (separate; handled by the release workflow).
Notes
- Versioned image tags only become meaningful once the first release is tagged; an
edgetag onmaincan cover the interim.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with Dockerfile, action.yml, .github/workflows/container.yml, and docs/en/guides/lift-export-interop.md. Review the existing build and smoke-test job, then add release publishing to GHCR without pushing from pull requests or forks. Done means versioned release tags and latest are published, the pull-based Docker example is documented, and PR checks still build and smoke-test the image.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, github-actions, python
- Domain
- cloud, devops, documentation
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100