feat(node): official kth node Docker image + GHCR publish workflow#2
Conversation
Adds the first official Docker image of the kth node, alongside the existing base/ and gcc/ toolchain images. node/Dockerfile builds FROM the kthnode/gcc15-ubuntu24.04 toolchain and installs kth via 'conan install --requires=kth/<version> --deployer=direct_deploy --build=missing'. The kth package and its heavy dependencies are pulled prebuilt from packages.kth.cash; only pieces without a matching prebuilt for this profile (currently utxoz) are compiled, ~1-2 min. The runtime stage is a slim ubuntu:24.04 (~103 MB) carrying only the GCC 15 C++ runtime, the CA bundle and the kth binary, so it needs no package manager. build-node.yml is a reusable (workflow_call) + manually dispatchable workflow that builds node/ for a given version and pushes ghcr.io/<owner>/kth:<version> and :latest, authenticating with the built-in GITHUB_TOKEN (no secrets required).
|
Warning Review limit reached
More reviews will be available in 52 minutes and 17 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughAdds a GitHub Actions workflow that normalizes a version input and builds and pushes a ChangesKnuth Node Docker Image and CI Workflow
🎯 3 (Moderate) | ⏱️ ~20 minutes
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
node/Dockerfile (1)
11-12: ⚡ Quick winAvoid mutable base tags for release image builds.
Using
:latestforTOOLCHAINmakes rebuilds non-deterministic and can silently change produced binaries. Prefer an immutable version tag or digest pin.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@node/Dockerfile` around lines 11 - 12, The TOOLCHAIN ARG is using the mutable `:latest` tag which can change between builds and cause non-deterministic behavior. Replace the `:latest` tag in the TOOLCHAIN variable with a specific immutable version tag (e.g., a specific version number like :1.0.0) or a digest pin (using `@sha256`:...) to ensure consistent and reproducible builds.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/build-node.yml:
- Around line 25-29: The workflow uses mutable action version tags and contains
security/reproducibility issues. Update the checkout action at line 25 and all
other action invocations (lines 38, 40, 46) by replacing floating version tags
like `@v4` with pinned commit SHAs, removing the forced ref: master parameter from
the checkout step to allow using the actual triggering reference, and adding
persist-credentials: false to the checkout step to prevent unnecessary git
credentials from persisting after checkout. These changes should be applied
consistently across all uses statements and checkout invocations in the workflow
file.
- Around line 30-35: The meta step directly injects the inputs.version workflow
input into a shell script without validation, creating a potential shell
injection vulnerability where crafted values containing quotes or newlines could
break out of the assignment. Add validation to ensure inputs.version matches a
strict format (such as semantic versioning with optional leading v prefix)
before it is used in the version assignment on line 32. This validation should
be added as a check before the variable is written to GITHUB_OUTPUT to prevent
malicious input from compromising the shell script execution.
In `@node/Dockerfile`:
- Around line 37-63: The runtime Dockerfile stage runs the kth process as the
root user, which creates a security vulnerability for a long-running
network-facing service. Add a non-root user to the runtime stage by creating a
new user (such as "kth") before the WORKDIR directive, ensure the /data
directory and /opt/kth/lib directory are owned by this user, and add a USER
directive before the ENTRYPOINT instruction to switch from root to the newly
created non-root user when the container starts.
---
Nitpick comments:
In `@node/Dockerfile`:
- Around line 11-12: The TOOLCHAIN ARG is using the mutable `:latest` tag which
can change between builds and cause non-deterministic behavior. Replace the
`:latest` tag in the TOOLCHAIN variable with a specific immutable version tag
(e.g., a specific version number like :1.0.0) or a digest pin (using
`@sha256`:...) to ensure consistent and reproducible builds.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 98a4e006-3075-4f60-b4f0-30055964ae58
📒 Files selected for processing (2)
.github/workflows/build-node.ymlnode/Dockerfile
Addresses review feedback: - Dockerfile: add an unprivileged 'kth' user, own /data, and USER kth before the entrypoint instead of running the node as root. - build-node.yml: validate the version input against a strict pattern via an env var (avoids shell injection from workflow inputs) and set persist-credentials: false on checkout. Action refs and the toolchain tag are kept as-is for consistency with the existing knuth.yml workflow and the repo's :latest toolchain convention.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/build-node.yml:
- Line 40: The version regex pattern in the version validation check is too
permissive and allows `+` characters which are invalid for Docker tags. Modify
the regex pattern by removing the `+` character from the prerelease version
separator portion (currently `[-+.]`) to only allow `-` and `.` as separators,
ensuring that only valid Docker-compatible version strings pass validation. This
will prevent version strings like `1.0.0+meta` from being accepted and used as
Docker tags later in the workflow at line 65.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 273f3270-8a1b-4ae4-9e7b-3abd96200eb6
📒 Files selected for processing (2)
.github/workflows/build-node.ymlnode/Dockerfile
🚧 Files skipped from review as they are similar to previous changes (1)
- node/Dockerfile
Drop '+' from the accepted version pattern: Docker tags allow only [A-Za-z0-9_.-], so a value like 1.0.0+meta would pass validation but fail at push time. Reject it up front instead.
- Move node/Dockerfile to kth/Dockerfile so the directory name matches the published image (ghcr.io/k-nuth/kth) and the project naming convention elsewhere in the org. - Update build context in build-node.yml accordingly. - Bump pinned action versions: actions/checkout v4 → v7 docker/setup-buildx-action v3 → v4 docker/login-action v3 → v4 docker/build-push-action v6 → v7
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/build-node.yml (1)
64-66: 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick winDon't push
:latestfor prerelease builds.This workflow accepts prerelease inputs, but it always publishes
:latest. A run for1.2.0-rc.1would replace the stable latest tag with an RC image.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/build-node.yml around lines 64 - 66, The image tagging in the build workflow always publishes the latest tag, which should be skipped for prerelease releases. Update the tag generation/publish logic in the workflow so the step that uses steps.meta.outputs.image and steps.meta.outputs.version only includes the latest tag for stable releases, and omits it when the version is a prerelease. Use the existing metadata/version handling in the workflow to distinguish prerelease inputs from normal releases.
🧹 Nitpick comments (1)
.github/workflows/build-node.yml (1)
25-27: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winUpdate the checkout note to match the renamed build context.
This comment still points maintainers at
node/, but the build now uses./kthon Line 60. Keeping the old path here is needlessly misleading.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/build-node.yml around lines 25 - 27, The checkout note in the reusable workflow is outdated and still refers to the old node/ build context. Update the comment near the repository/ref checkout logic to match the current ./kth build context used by the workflow so maintainers aren’t misled; keep the wording aligned with the checkout step and the build setup it supports.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/build-node.yml:
- Around line 39-41: The version validation in the build workflow currently
allows prerelease suffixes to start with either a dot or a hyphen, which lets
malformed versions slip through. Update the regex in the version-check block
that derives and validates INPUT_VERSION so prerelease segments can only begin
with a hyphen, while still accepting valid semver prereleases in the same place.
---
Outside diff comments:
In @.github/workflows/build-node.yml:
- Around line 64-66: The image tagging in the build workflow always publishes
the latest tag, which should be skipped for prerelease releases. Update the tag
generation/publish logic in the workflow so the step that uses
steps.meta.outputs.image and steps.meta.outputs.version only includes the latest
tag for stable releases, and omits it when the version is a prerelease. Use the
existing metadata/version handling in the workflow to distinguish prerelease
inputs from normal releases.
---
Nitpick comments:
In @.github/workflows/build-node.yml:
- Around line 25-27: The checkout note in the reusable workflow is outdated and
still refers to the old node/ build context. Update the comment near the
repository/ref checkout logic to match the current ./kth build context used by
the workflow so maintainers aren’t misled; keep the wording aligned with the
checkout step and the build setup it supports.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 2901447c-f5d2-452c-963b-889230dc7b9d
📒 Files selected for processing (2)
.github/workflows/build-node.ymlkth/Dockerfile
💤 Files with no reviewable changes (1)
- kth/Dockerfile
- Tighten the version regex: only `-` may introduce a prerelease suffix. `1.2.3.rc1` (dot-separated) used to slip past the guard and fail later in conan; now it's rejected up front. - Skip the `:latest` tag for prereleases. An `-rc.N` build no longer displaces the stable `:latest` — only X.Y.Z without a `-` suffix publishes `:latest`. - Pin the toolchain image by sha256 digest instead of `:latest`. A future retag of `gcc15-ubuntu24.04:latest` would otherwise silently change the binaries we produce. Bump the digest deliberately when the toolchain moves. - Fix a stale comment that still pointed at `node/` after the rename to `kth/`.
The previous README ("Helper Docker Images" + one build command) no
longer describes what the repo contains. After the kth/ node image
landed (PR #2), there are two distinct concerns living here: the
toolchain images consumed by CI, and the end-user node image
consumed by operators.
Spell that out: who each image is for, where it's published, what
triggers a rebuild, and how to build any of them by hand.
2 participants
Official
kthnode Docker imageThis adds the first Docker image of the kth node itself, next to the existing
base/andgcc/toolchain images. Right now there is no published node image anywhere, so users haveto compile kth themselves; this closes that gap and gives
ghcr.io/k-nuth/ktha real image.How it builds
node/Dockerfilebuilds FROMkthnode/gcc15-ubuntu24.04(your toolchain), so thecompile profile matches the binaries on
packages.kth.cash.conan install --requires=kth/<version> --deployer=direct_deploy --build=missing.kthand the heavy deps (boost, openssl, lmdb, gmp, ftxui, simdjson…) come down prebuilt;the only thing currently rebuilt for this profile is
utxoz/0.8.0(~1–2 min), because noprebuilt is published for
cppstd=23.--build=missingkeeps this self-healing if afuture release lacks a prebuilt for any piece.
ubuntu:24.04(~103 MB) carrying only the GCC 15 C++runtime, the CA bundle and the
kthbinary — no package manager, nothing else.The workflow
.github/workflows/build-node.ymlis reusable (workflow_call) and also runnable by hand(
workflow_dispatch). It buildsnode/for a given version and pushesghcr.io/<owner>/kth:<version>and:latest, authenticating with the built-inGITHUB_TOKEN. The companion PR onk-nuth/kthcalls this onevery release; until then you can build any version manually from the Actions tab.
Tested
Built
v1.0.0locally end to end; the resulting image runs:One-time note
After the first publish, the new
kthpackage under Packages will be private by default —it just needs to be set to public once.
Summary by CodeRabbit
New Features
Improvements