Skip to content

ci: publish dev runtime images on main #5

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
KAJdev wants to merge 1 commit into
base: main
Choose a base branch
from
+9 −2
Open

ci: publish dev runtime images on main #5

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions .github/workflows/images.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,6 +13,8 @@ on:
description: Runpod SDK package spec
required: true
default: runpod
push:
branches: [main]

@deanq deanq Oct 29, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's no concurrency group, so two merges to main in quick succession run this workflow in parallel, and both push the same -dev tags. The 30 runtime jobs and 5 base jobs of the two runs finish in any order, so the result can be task-gpu:py3.12-dev from the newer run next to queue-gpu:py3.12-dev from the older one. A runtime job can also build on top of a gpu-base:pyX-dev that the other run has just replaced. Could the workflow get something like concurrency: { group: images-${{ github.event_name }}-${{ github.ref }}, cancel-in-progress: true } so only the newest push publishes?

Comment on lines +16 to +17

permissions:
contents: read
Expand All @@ -35,6 +37,10 @@ jobs:
tag="${RELEASE_TAG#v}"
sdk_spec="runpod"
release_tags="true"
elif [ "${{ github.event_name }}" = "push" ]; then
tag="dev"
sdk_spec="https://github.com/runpod/runpod-python/archive/refs/heads/main.tar.gz"

@deanq deanq Oct 29, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because this URL is the same on every run, RUNPOD_PACKAGE_SPEC doesn't change either, so the pip install "${RUNPOD_PACKAGE_SPEC}" layer is only rebuilt when pyproject.toml, README.md or src change (the COPY lines above it). A push that only touches workflows or tests gets a cache hit from type=gha and republishes -dev with whatever SDK main was the last time the layer was built. Separately, a change on runpod-python main doesn't trigger this workflow, so -dev lags SDK main until the next push here, and since the version is pretended to be 0.0.0.dev0 there's no way to tell from the image which SDK commit it has. Could prepare resolve the current SHA (git ls-remote https://github.com/runpod/runpod-python refs/heads/main) and use archive/<sha>.tar.gz? That rebuilds the layer whenever SDK main moves, keeps it cached when it hasn't, and puts the commit in the build log. An OCI label with the SHA would make it visible on the image too.

release_tags="false"
else
tag="$INPUT_TAG"
sdk_spec="$INPUT_SDK_SPEC"
Expand Down
5 changes: 3 additions & 2 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -20,8 +20,9 @@ packages excluded from GPU deployment artifacts.
| `runpod/task-gpu:py3.12-latest` | ephemeral GPU task pods |

Python 3.10 through 3.14 are published. Release tags use
`py<python>-<runtime-version>`, and `latest` tracks the newest release. Manual image
publishes support channels such as `dev`.
`py<python>-<runtime-version>`, and `latest` tracks the newest release. Pushes to
`main` publish `py<python>-dev` images using the SDK's `main` branch. Manual image
publishes support custom tag suffixes and SDK package sources.

## Package

Expand Down
Loading