[DevOps]: create a Docker image version on NemoClaw per version of OpenClaw

Open
#62 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
docker, github-actions
Domain
ci-cd, devops

Research direction

Review PR #55 and the current NemoClaw image build first; use npm view openclaw versions --json to understand the version source. Define the recurring repository workflow so each available OpenClaw version produces a NemoClaw image with an OpenClaw-version tag, and verify the optional dual-tag behavior if adopted.

Written by the indexing model from the issue text.

Description

@johntmyers : this is a continuation of https://github.com/NVIDIA/OpenShell-Community/pull/55 based on your remrark.

Currently, NemoClaw image defines and uses 1 single OpenClaw version in its buzild. Frequent updates would be needed to keep it up to date as OpenClaw evolves very fast.

A much better approach is to build one version of the NemoClaw image for OpenClaw for each OpenClaw version. The list of available OpenClaw packages is easy to obtain via the command below

So, it would be good to let the user choose the version of OpenClaw that he wants by having 1 image available for each of those versions.

Consequently, there should be a workflow in this repo running regurlary and creating new versions of NemoClaw when new versions of OpenClaw get publshed. Those images would be tagged ith the version of OpenClaw.

Optionally, those images could have a dual tag + as NemoClaw also gets updated to offer choices in the 2 dimensions

npm view openclaw versions --json
[
  "0.0.1",
  "2026.1.29-beta.1",
  "2026.1.29-beta.2",
  "2026.1.29-beta.3",
  "2026.1.29-beta.4",
  "2026.1.29-beta.5",
  "2026.1.29-beta.7",
  "2026.1.29",
  "2026.1.30",
  "2026.2.1",
  "2026.2.2-1",
  "2026.2.2-2",
  "2026.2.2-3",
  "2026.2.2",
  "2026.2.3-1",
  "2026.2.3",
  "2026.2.6-1",
  "2026.2.6-2",
  "2026.2.6-3",
  "2026.2.6",
  "2026.2.9",
  "2026.2.12",
  "2026.2.13",
  "2026.2.14",
  "2026.2.15",
  "2026.2.17",
  "2026.2.19-1",
  "2026.2.19-2",
  "2026.2.19",
  "2026.2.21-1",
  "2026.2.21-2",
  "2026.2.21",
  "2026.2.22-1",
  "2026.2.22-2",
  "2026.2.22",
  "2026.2.23-beta.1",
  "2026.2.23",
  "2026.2.24",
  "2026.2.25-beta.1",
  "2026.2.25",
  "2026.2.26",
  "2026.3.1-beta.1",
  "2026.3.1",
  "2026.3.2-beta.1",
  "2026.3.2",
  "2026.3.7-beta.1",
  "2026.3.7",
  "2026.3.8-beta.1",
  "2026.3.8",
  "2026.3.11-beta.1",
  "2026.3.11",
  "2026.3.12",
  "2026.3.13-beta.1",
  "2026.3.13",
  "2026.3.22-beta.1",
  "2026.3.22",
  "2026.3.23-1",
  "2026.3.23-2",
  "2026.3.23-beta.1",
  "2026.3.23",
  "2026.3.24-beta.1",
  "2026.3.24-beta.2",
  "2026.3.24",
  "2026.3.28-beta.1",
  "2026.3.28",
  "2026.3.31-beta.1",
  "2026.3.31",
  "2026.4.1-beta.1",
  "2026.4.1",
  "2026.4.2"
]

Dominant language
Dockerfile
Stars
191
Forks
76
PR merge metrics
No merged PRs in 30d

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.

More from NVIDIA/OpenShell-Community

All issues in NVIDIA/OpenShell-Community

Similar issues

More DevOps issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.