Various fixes to container image and CI

[sjmonson]

Summary

Various fixes to containers images and CI. Containers images should now reuse most layers on build, need less hacks when running in OCP, and properly detect the guidellm version. Release and RC git tags/branches tag the container image with the version. The latest and stable tags now smartly update based on highest version tag (prev most recent build).

Details

• Moves Containerfile to top-level
• Adds a .containerignore that mirrors .gitignore
• Fixes version detection in image builds
• Correctly sets release type and tags rc/release with version when building images
• Use PDM to lock venv in image builds
• Adds weekly job for tagging latest and stable based on existing version tagged images
• Adds weekly job to prune dev containers that are more than 2 weeks old
  • Note: This job is currently set to dry-run and will be enabled in a future PR
• Improves container compatibility with K8s unpriv users
• Reorders image layers to improve build caching

Test Plan

1. Workflows

• Workflows were partially tested with act but need to be run on GitHub to verify

2. Container Changes

1. Run podman run --rm ghcr.io/vllm-project/guidellm:pr-254 --version to verify version is set
2. Run podman run --rm --entrypoint /opt/app-root/guidellm/bin/pip ghcr.io/vllm-project/guidellm:pr-254 freeze and verify that versions match the pylock.toml.
3. Run a pod with the GuideLLM container and verify the user has write permissions to /home/guidellm. (For tokenizer/dataset caching)

Related Issues

• Resolves #

---

• "I certify that all code in this PR is my own, except as noted below."

Use of AI

• Includes AI-assisted code completion
• Includes code generated by an AI application
• Includes AI-generated tests (NOTE: AI written tests should have a docstring that includes ## WRITTEN BY AI ##)

[Copilot]

Pull Request Overview

This PR refactors the container image build process and CI workflows to improve caching, fix version detection, and automate container maintenance. The changes move the Containerfile to the root directory, improve image layer ordering for better build caching, and add automation for tagging latest/stable versions and cleaning up development images.

• Relocated Containerfile from deploy/ to root directory with improved layer caching strategy
• Enhanced CI workflows to properly tag container images with versions and build types
• Added automated container maintenance workflow for cleaning up old PR images and updating latest/stable tags

Reviewed Changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
deploy/Containerfile	Removed old Containerfile from deploy directory
Containerfile	New Containerfile at root with improved caching and PDM integration
README.md	Added documentation for available container image tags
.github/workflows/release.yml	Updated to use new Containerfile path and tag with version
.github/workflows/release-candidate.yml	Updated to use new Containerfile path and tag RC versions
.github/workflows/nightly.yml	Updated to use new Containerfile path and set nightly build type
.github/workflows/development.yml	Updated to use new Containerfile path and set dev build type
.github/workflows/container-maintenance.yml	New workflow for automated container cleanup and tag management
.containerignore	Added container ignore file referencing .gitignore

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[sjmonson]

Set this to dry-run for now until we can confirm it deletes the correct set of images.

[jaredoconnell]

Looks good to me. I left one comment.

[jaredoconnell]

I don't love the burden of maintaining our own version of the python container. Is it set up to automatically update when the base container updates? If not there are security concerns.
The bug you referenced regarding Python 3.12 appears to be resolved, according to Mark.
I don't see any value to using the state of the art python version when the project is backwards compatible to 3.9, but I won't block you on it.

[sjmonson]

I don't love the burden of maintaining our own version of the python container. Is it set up to automatically update when the base container updates? If not there are security concerns. The bug you referenced regarding Python 3.12 appears to be resolved, according to Mark. I don't see any value to using the state of the art python version when the project is backwards compatible to 3.9, but I won't block you on it.

Adding some offline discussion here:

• Regarding Long running test spawn too many threads #196; the bug is mitigated in v0.3.0 but is still present since its an issue with the interaction between SyncManager, ProcessPoolExecutor, and asyncio. There is also High concurrency benchmarks (rate >= 24) cause unhandled ConnectionRefusedError on shutdown #329 which is confirmed on Python 3.10 and confirmed fixed on 3.13. Both should be fixed in v0.4.0 due to us dropping the ProcessPoolExecutor.
• The upstream container image should be built for Python 3.13 soon. For the short-term we will maintain our own python container image based on the upstream PR. If the upstream image is not available in the next couple months we will consider next steps such as downgrading to a 3.12 image.

[Copilot]

Pull Request Overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated no new comments.

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}