بناء الصورة ودفعها عند الإصدار

You do not ship an image on every commit. The release step builds and publishes a container only when you mark a version as ready. 📦

A common pattern fires the build when you push a git tag like v1.2.0, so a deliberate version, not a casual push, starts the deploy.

The build packs your model API, its code, and dependencies into one image: a frozen, runnable snapshot that behaves the same on any machine.

A container registry like GHCR, ECR, or Docker Hub is where built images live so any server can later pull and run them.

Before pushing, the workflow logs into the registry using a stored secret, never a hardcoded password, keeping credentials out of your code.

Give the image a clear tag that matches your release version. Reusing latest alone makes it impossible to tell which build is running.

The official Docker build-push action builds your Dockerfile and uploads the result to the registry in a single step.

Deploying a pinned tag like v1.2.0 means you always know exactly which model and code are live, and you can roll back to an earlier tag fast.

Image builds reuse unchanged layers from a cache, so only the parts you actually changed rebuild. This keeps release builds quick.

Once pushed, your runtime simply pulls the tagged image and starts it. The same artifact you tested is the one that goes live, byte for byte.

Tie the image tag to a GitHub release with notes on what changed. Now anyone can trace a running container back to its exact code and model.

Why tag the released image with a version instead of only latest?

On a version tag, log in with a secret, build the image, and push it to a registry under a pinned tag. Your runtime pulls that exact artifact to go live.