chore: upgrade Hermes from 2026.4.8 to 2026.4.23#2745
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughVersion bump updates for the Hermes agent component. The Docker build argument Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Review rate limit: 9/10 reviews remaining, refill in 6 minutes. Comment |
|
✨ Thanks for submitting this PR that proposes an update to the Hermes Agent from version 2026.4.8 to 2026.4.23. This change updates the dependency and includes code changes, which could improve the overall functionality of NemoClaw with the Hermes integration. |
…2846) This is a maintainer experiment that builds on Ben Barclay's PR #2834. Ben identified the right install gap: the Hermes image needs the dependencies required for supported runtime integrations, otherwise users hit missing-package failures after onboarding. This branch keeps that direction while narrowing the dependency surface for NemoClaw: - targets the selected Hermes release `v2026.4.23` / `0.11.0` - verifies the GitHub release tarball by SHA256 before extraction - installs Hermes with `uv sync --frozen --no-dev --extra messaging --extra web` by default instead of `[all]` - preserves the `/usr/local/bin/hermes` final-image contract used by policy and e2e checks - grants the Hermes gateway group write access to runtime state directories while keeping config files non-group-writable - opens `/tmp/gateway.log` from inside the `gateway` user context so capability-dropping does not block startup - updates the Hermes manifest expected version to `2026.4.23` - leaves OpenClaw dependency handling unchanged The intent is to prebake the Hermes dependencies that map to NemoClaw-supported onboarding integrations today: Telegram, Discord, Slack, and the API/health runtime. Larger or unsupported integrations should stay out of the base image and be installed by the agent workflow when enabled. Local validation completed: - `docker build --progress=plain -f agents/hermes/Dockerfile.base -t nemoclaw-hermes-base-experiment .` - `docker build --progress=plain -f agents/hermes/Dockerfile.base --build-arg HERMES_VERSION=v2026.4.13 --build-arg HERMES_TARBALL_SHA256=5e4529b8cb6e4821eb916b81517e48125109b1764d6d1e68a204a9f0ddf2d98c --build-arg HERMES_UV_EXTRAS=messaging -t nemoclaw-hermes-old-base-e2e-rebuild-test .` - `docker build --progress=plain -f agents/hermes/Dockerfile --build-arg BASE_IMAGE=nemoclaw-hermes-base-experiment -t nemoclaw-hermes-final-experiment .` - final image resolves `hermes` to `/usr/local/bin/hermes` and reports `Hermes Agent v0.11.0 (2026.4.23)` - imports present: `telegram`, `discord`, `slack_bolt`, `fastapi`, `uvicorn` - imports absent: `faster_whisper`, `mautrix`, `boto3`, `dingtalk_stream`, `lark_oapi` - entrypoint gateway health check returns `{"status":"ok","platform":"hermes-agent"}` through port `8642` - `npm test -- test/sandbox-provisioning.test.ts src/lib/agent-defs.test.ts src/lib/sandbox-version.test.ts` - `npm run validate:configs` - `npm run typecheck:cli` - `npx prek run --all-files --stage pre-push` Focused e2e passed on this branch: https://github.com/NVIDIA/NemoClaw/actions/runs/25222726016 Earlier focused e2e on this experiment found four useful issues that this branch now addresses: first the image contract expected `/usr/local/bin/hermes`, then the gateway needed writable Hermes runtime state under `/sandbox/.hermes`, then the entrypoint opened `/tmp/gateway.log` before switching to the `gateway` user. The rebuild e2e also needed its old-version fixture pinned to the matching tarball checksum and extras profile. The final OpenShell-specific blocker was that the Hermes executable is a symlink into /opt/hermes, so the Hermes policy now grants read-only access to that venv path. Related context: - Contributor PR: #2834 - Hermes version selection context: #2745 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Enhanced startup logging with improved diagnostics for troubleshooting sandbox initialization issues * Added runtime diagnostics to capture system state and logs when errors occur * **Chores** * Updated Hermes agent to v2026.4.23 * Improved build pipeline with better dependency verification and deterministic installation <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Ben Barclay <ben@nousresearch.com>
|
Thanks for putting this together @benbarclay! 🙏 This version bump has already landed on main via #2846 (which also added tarball SHA-256 verification and switched to a UV-based install). Closing as superseded — no action needed on your end. |
Summary
This updates to the latest tagged release of Hermes Agent
Changes
Hermes Agent v2026.4.8 -> v2026.4.23
Type of Change
Verification
npx prek run --all-filespasses - this throws a system permissions error on my linux machinenpm testpasses - there's a single failing test, which is also failing on mainmake docsbuilds without warnings (doc changes only)Signed-off-by: Ben Barclay ben@nousresearch.com
Summary by CodeRabbit