Add Docker Hub tag monitoring workflow - #621
Merged
Merged
Conversation
Creates a CRON workflow that: - Runs daily at 6:00 UTC to check for new Docker image releases - Monitors SGLang (CUDA/ROCm) and vLLM (CUDA/ROCm) images - Compares Docker Hub tags with current config versions - Creates a GitHub issue with @claude trigger when updates are found The workflow will help automate the process of discovering and implementing Docker image updates for both NVIDIA and AMD platforms. Resolves #454 Co-authored-by: Bryan Shan <Oseltamivir@users.noreply.github.com>
Collaborator
|
@Oseltamivir nit: how do u handle different rocm and cuda versions i.e. for nvidia sglang 0.5.8, they have both cuda 13 and cuda 12.9 
|
Collaborator
|
W in chat! |
Collaborator
Author
Collaborator
|
Claude finished @Oseltamivir's task in 1m 16s —— View job Refactored Docker Tag Monitor to Claude Agent ApproachTask: Change the workflow to use a Claude agent that runs weekly, checks for vLLM/SGLang releases, and creates issues with
Changes MadeBefore: 291 lines of Python/JavaScript embedded in the workflow
After: 97 lines using Claude agent (67% reduction)
How It Works
Addressing @functionstackx's Question
The Claude agent approach handles this more flexibly:
This is more adaptable than regex patterns since Claude can reason about which variant to recommend. | |
Replace 290+ lines of Python/JavaScript with a simple Claude agent workflow: - Runs weekly on Mondays (instead of daily) - Uses Claude to intelligently check Docker Hub for releases - Creates issues with @claude trigger when updates are found - Supports dry-run mode for testing The Claude agent approach: 1. Fetches latest tags from Docker Hub API 2. Compares with current versions in config files 3. Creates detailed issue with update table if needed 4. Triggers another Claude instance via @claude mention Co-authored-by: Bryan Shan <Oseltamivir@users.noreply.github.com>
cquil11
reviewed
Feb 3, 2026
| 1. **Check Docker Hub for latest releases:** | ||
| - SGLang CUDA: `lmsysorg/sglang` - tags matching `v*-cu*-amd64` (e.g., v0.5.8-cu129-amd64) | ||
| - SGLang ROCm: `lmsysorg/sglang` - tags matching `v*-rocm*-mi*` (e.g., v0.5.8-rocm700-mi35x) | ||
| - vLLM CUDA: `vllm/vllm-openai` - tags matching `v*.*.*` (e.g., v0.13.0) |
Collaborator
There was a problem hiding this comment.
ik u put the regex here but prolly wanna just specify in english that we only want major minor patch releases, not nightly image builds
cquil11
approved these changes
Feb 3, 2026
cquil11
left a comment
cquil11
left a comment
Collaborator
There was a problem hiding this comment.
lgtm other than one comment
Oseltamivir
added a commit
that referenced
this pull request
Aug 5, 2026
DeepEP's low-latency combine corrupts the 256 tokens/rank rung on every Blackwell SKU we run -- B200, GB200 and GB300, EP8 and EP16, both precisions, MNNVL and RDMA alike -- while Hopper stays clean. It is stochastic at roughly 1.5-3.3% per invocation and surfaces as one wrong token row whose norm still matches, so the correctness gate catches it as a 0.07-6.6 relative error against a 0.03125 tolerance. Tracked upstream as DeepEP issue #700. Clamp the measured low-latency ladder to 128 and leave the receive sized at 256. The two are now separate constants on purpose: the receive footprint drives the transport's memory traffic and the FP8 dequant volume, so sizing it from max(ladder) -- as it was -- would have halved it the moment the ladder moved and shifted every retained rung out of comparability with the published series. Holding it at 256 also leaves the top measured rung at half occupancy, which is the ladder/capacity decoupling the original capacity probe had to hand-roll. The clamp is not silent: the harness already reports every dropped ladder point into the artifact. The likely upstream fix is DeepEP PR #642, which adds a CTA-scope fence so the combine consumer's shared-memory reads retire before the stage is recycled and the producer's next TMA load refills it -- that mechanism predicts the observed signature, and it closed #621, the same race reached from NVL72. Our pin is the head of PR #605 and was branched before #642 merged, so the fence is simply absent from our build. Raising the ladder back to 256 is therefore gated on a pin bump, deliberately not bundled here: it spans months of upstream change, re-baselines every deepep-v2 row including normal mode, and needs rewrite_deepep_v2 made tolerant first, since main already carries the 'libnccl' fix that rewrite asserts it must apply.
Oseltamivir
added a commit
that referenced
this pull request
Aug 5, 2026
…lamp Fixes the defect instead of stepping around it. b368eae clamped the low-latency ladder to 128 so the corrupt 256 rung was not measured; the corruption itself was still in the kernels we publish numbers from, at roughly 1.5-3.3% per invocation on every Blackwell SKU. The fix was already upstream. DeepEP PR #642 adds a CTA-scope fence.proxy.async.shared::cta before mbarrier_arrive(empty_barriers[stage_idx]) in LOW_LATENCY_COMBINE_RECV, so the combine consumer's shared-memory reads retire before the stage is declared empty and the producer's next TMA load refills it -- signalling empty too early is what let one output row be assembled from two tiles, which matches the observed signature exactly (norm preserved to 4 s.f., 16-40% of elements wrong). It closed #621, the same race found independently on NVL72. COLLX_DEEPEP_V2_COMMIT was fa8a9b16, the head of the pre-merge PR #605 branch, cut before #642 landed. Its one unique commit was the #630 single-node V2 init fix, which main carries as 56169594e, so moving to main loses nothing and also picks up #715 (system-scope release before the GIN barrier when scale-up spans NVLink and RDMA), #688 (NCCL Device API: runtime version for ncclDevCommCreate), #178 (SM90), #641, and #640/#627 upstream's own libnccl and SO-name handling. Verified before bumping that main still exposes every API this adapter calls: legacy Buffer kwargs incl. allow_mnnvl, get_low_latency_rdma_size_hint, low_latency_dispatch/combine, ElasticBuffer's full kwarg set, topk_idx_t, and the fp8 cast helpers. rewrite_deepep_v2 now succeeds when the source already matches, because main contains #640 and the old count(old) == 1 assertion would have aborted every leg at repository-stage. Verified against all four source states: old form rewrites, fixed form is a no-op, absent and duplicated forms still fail. _LL_LADDER_CAP returns to 256. The two constants stay separate: the receive must not be sized from max(ladder), or clamping the ladder would change the footprint that drives transport traffic and fp8 dequant volume. The cap test now asserts ladder <= buffer -- strict inequality encoded the workaround, not an invariant. The backend cache key includes the pin, so this forces a rebuild rather than reusing the old build.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Resolves #454
Generated with Claude Code