sillsdev / sillsdev/python-sil-lift

Publish the sil-lift container image to GHCR

Open
#4 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
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 new release-triggered workflow) that builds and pushes to GHCR using GITHUB_TOKEN with permissions: packages: write.
  • Tags: vX.Y.Z plus a moving latest on each GitHub Release; optionally an edge/sha tag on pushes to main for 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 of Dockerfile, so uses: sillsdev/python-sil-lift@vX doesn'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 edge tag on main can cover the interim.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.