Conversation
Bumps node from 16.13.2-alpine to 18.0.0-alpine. --- updated-dependencies: - dependency-name: node dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
📝 WalkthroughWalkthroughNode.js base image versions are updated in two Dockerfiles. The main Dockerfile is upgraded from node:16.13.2-alpine to node:18.0.0-alpine, and Dockerfile.openapi_decorator is upgraded from node:14-alpine to node:18-alpine. Both changes maintain the same container structure and build stages. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 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 |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@Dockerfile`:
- Line 6: The Dockerfile base image uses "FROM
node:18.0.0-alpine@sha256:505bb54d..." which is EOL; update this FROM
instruction to a currently maintained Node LTS (recommend "node:24-alpine" or
"node:22-alpine" as fallback), and either remove the old sha256 digest or
replace it with the correct digest for the chosen tag so the base stage name "as
base" remains valid and image pulls succeed. Ensure any other Dockerfiles or CI
references are updated to the same Node LTS tag if they rely on this image.
In `@Dockerfile.openapi_decorator`:
- Line 1: The Dockerfile uses the floating base image tag "node:18-alpine" in
the FROM line which can drift; update that FROM line to pin the exact image
digest (e.g., use the same sha256 digest used by the project's main Dockerfile)
so the base image is deterministic and supply-chain safe—locate the FROM line in
Dockerfile.openapi_decorator and replace "node:18-alpine" with the digest-pinned
reference (node:18-alpine@sha256:...) taken from the canonical Dockerfile or the
official Node image manifest.
| # BASE IMAGE | ||
| # -------------------------------------------------------------------------------- | ||
| FROM node:16.13.2-alpine@sha256:f21f35732964a96306a84a8c4b5a829f6d3a0c5163237ff4b6b8b34f8d70064b as base | ||
| FROM node:18.0.0-alpine@sha256:505bb54d5a7380b805d68db9822dd20844c0d348f4f96ccc57e1a240cba57236 as base |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Node.js 18 end of life date EOL schedule
💡 Result:
Node.js v18 (Hydrogen) lifecycle (upstream OpenJS/Node.js project):
- Initial release: 2022-04-19 [1]
- Active LTS start: 2022-10-25 [1]
- Maintenance LTS start: 2023-10-18 [1]
- End of life (EOL): 2025-04-30 (no further upstream security/bugfix releases after this date) [1]
As of January 23, 2026, Node.js 18 is past EOL. [2]
Sources: Node.js Release Working Group schedule [1], Node.js releases page [2].
🌐 Web query:
Node.js LTS release schedule 2026 current supported versions
💡 Result:
Currently supported Node.js major lines (as of Jan 23, 2026)
- v25 — Current (latest “Current” line) [1]
- v24 (Krypton) — Active LTS [1]
- v22 (Jod) — Maintenance LTS [1]
- v20 (Iron) — Maintenance LTS (still supported, but nearing EOL) [1]
Key 2026 LTS/support schedule dates (official)
From the Node.js Release Working Group schedule: [2]
- Node.js 20.x EOL: 2026-04-30 [2]
- Node.js 25.x maintenance starts: 2026-04-01; 25.x EOL: 2026-06-01 (odd releases do not become LTS) [2]
- Node.js 24.x moves from Active LTS → Maintenance: 2026-10-20 [2]
Release cadence (what to expect in 2026)
- New major versions are branched every April and October; even majors are released in April and later transition to LTS when the next odd major ships in October. [2]
Sources: [1] Node.js “Releases / Previous releases” page; [2] nodejs/Release (Release Working Group) schedule & policy.
Upgrade Node.js to a maintained LTS version.
Node.js 18 reached end-of-life on April 30, 2025, and is no longer receiving security updates. Upgrade to an active LTS version: v24 (Krypton, Active LTS) is recommended, or v22 (Jod, Maintenance LTS) as an alternative. Node.js v20 is also still supported but approaches EOL on April 30, 2026.
🤖 Prompt for AI Agents
In `@Dockerfile` at line 6, The Dockerfile base image uses "FROM
node:18.0.0-alpine@sha256:505bb54d..." which is EOL; update this FROM
instruction to a currently maintained Node LTS (recommend "node:24-alpine" or
"node:22-alpine" as fallback), and either remove the old sha256 digest or
replace it with the correct digest for the chosen tag so the base stage name "as
base" remains valid and image pulls succeed. Ensure any other Dockerfiles or CI
references are updated to the same Node LTS tag if they rely on this image.
| @@ -1,4 +1,4 @@ | |||
| FROM node:14-alpine | |||
| FROM node:18-alpine | |||
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Find all Dockerfiles in the repository
find . -type f -name "Dockerfile*" | head -20Repository: Madib036/docs
Length of output: 127
🏁 Script executed:
# Check the content of the main Dockerfile to see if it pins digests
git ls-files | grep -i dockerfile | head -10Repository: Madib036/docs
Length of output: 656
🏁 Script executed:
# Check the main Dockerfile content
cat -n DockerfileRepository: Madib036/docs
Length of output: 3766
🏁 Script executed:
# Check the devcontainer Dockerfile
cat -n .devcontainer/DockerfileRepository: Madib036/docs
Length of output: 1328
🏁 Script executed:
# Confirm the openapi_decorator file
cat -n Dockerfile.openapi_decoratorRepository: Madib036/docs
Length of output: 721
Pin the Node image digest to prevent drift and supply-chain risk.
The main Dockerfile pins node:18.0.0-alpine@sha256:..., but this file uses a floating node:18-alpine tag which can silently change builds. Pin the digest for consistency and to eliminate supply-chain vulnerabilities.
Suggested change
-FROM node:18-alpine
+FROM node:18-alpine@sha256:<digest>🤖 Prompt for AI Agents
In `@Dockerfile.openapi_decorator` at line 1, The Dockerfile uses the floating
base image tag "node:18-alpine" in the FROM line which can drift; update that
FROM line to pin the exact image digest (e.g., use the same sha256 digest used
by the project's main Dockerfile) so the base image is deterministic and
supply-chain safe—locate the FROM line in Dockerfile.openapi_decorator and
replace "node:18-alpine" with the digest-pinned reference
(node:18-alpine@sha256:...) taken from the canonical Dockerfile or the official
Node image manifest.
Why:
Closes:
What's being changed (if available, include any code snippets, screenshots, or gifs):
Check off the following:
I have reviewed my changes in staging, available via the View deployment link in this PR's timeline (this link will be available after opening the PR).
datadirectory.For content changes, I have completed the self-review checklist.
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.