Skip to content

build: pin the node base image in every file that names one - #1009

Merged
cameri merged 2 commits into
mainfrom
fix/pin-node-base-images
Oct 31, 2026
Merged

cameri merged 2 commits into
mainfrom
fix/pin-node-base-images

Conversation

@chappie-daemon

Copy link
Copy Markdown
Collaborator

What

Dockerfile pinned node:24.22.1-alpine by digest in #1005, but four other files that name a node base image still said node:24-alpine:

file service / stage
Dockerfile.railwayapp Railway build stage + runtime stage
Dockerfile.test the CI test image
docker-compose.yml nostream-migrate
test/integration/docker-compose.yml migrations-test

All five now carry the same tag and digest.

Why it matters

A floating tag means the relay image, the CI image, the Railway image and both ephemeral migration containers can each start from a different base, and a release can run different node code than the one before it without a commit saying so.

Guard

test/unit/ci/node-base-pin.spec.ts collects every FROM node:… and image: node:… in the repo and asserts two things: each carries a digest, and all of them are the same reference. That second check is what #1005 lacked — it pinned Dockerfile and left the rest behind, and nothing noticed.

It also asserts the scan found the expected rows, so a glob that silently matches nothing cannot make the suite green.

Verification

  • new spec: 3 passing
  • reverting Dockerfile.test to node:24-alpine: fails on both counts (digest and single reference)
  • test/unit/ci/**: 26 passing

Dockerfile pinned node:24.22.1-alpine by digest, but Dockerfile.railwayapp,
Dockerfile.test and the two compose files still said node:24-alpine, so the
relay image, the CI image, the Railway image and both migration containers
could each start from a different base - and a floating tag moves under a
release, so the same commit built twice could run different node code.

All five now carry the same tag and digest, and a unit test holds them
together: it fails if any reference loses its digest, and it fails if two
different references appear, which is how #1005 left these behind.

Verified: the new spec passes; reverting Dockerfile.test to node:24-alpine
fails it on both counts; the rest of test/unit/ci is 26 passing.
@changeset-bot

changeset-bot Bot commented Oct 31, 2026 •

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: ad8c5c4

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
nostream Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@greptile-apps

greptile-apps Bot commented Oct 31, 2026 •

Copy link
Copy Markdown

RetriggerView in GreptileConfidence Score: 5/5

[Medium impact] The PR appears safe to merge; no blocking issues were identified.

Summary

Pins the remaining Node base images to the same tag and digest.

  • Railway and test images use the same pinned Node base.
  • Both migration containers use the same pinned Node image.
  • A unit test checks that every Node image reference stays in sync.

Reviews (2) · Last reviewed commit: "chore: changeset for the node base image..." · Reviewed by Greptile

greptile-apps[bot]
greptile-apps Bot previously approved these changes Oct 31, 2026
@coveralls

coveralls commented Oct 31, 2026 •

Copy link
Copy Markdown
Collaborator

Coverage Report for CI Build 41234711032

Coverage decreased (-0.006%) to 77.35%

Details

  • Coverage decreased (-0.006%) from the base build.
  • Patch coverage: No coverable lines changed in this PR.
  • No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.


Coverage Stats

Coverage Status
Relevant Lines: 11817
Covered Lines: 9554
Line Coverage: 80.85%
Relevant Branches: 6201
Covered Branches: 4383
Branch Coverage: 70.68%
Branches in Coverage %: Yes
Coverage Strength: 1551.91 hits per line

💛 - Coveralls

@cameri
cameri merged commit f7c57f4 into main Oct 31, 2026
22 of 24 checks passed
@cameri
cameri deleted the fix/pin-node-base-images branch October 31, 2026 20:00
chappie-daemon added a commit that referenced this pull request Oct 31, 2026
This PR was opened by the [Changesets
release](https://github.com/changesets/action) GitHub action. When
you're ready to do a release, you can merge this and the packages will
be published to npm automatically. If you're not ready to do a release
yet, that's fine, whenever you add more changesets to main, this PR will
be updated.


# Releases
## nostream@3.10.0

### Minor Changes

- [#922](#922)
[`fcb33de`](fcb33de)
Thanks [@Priyanshubhartistm](https://github.com/Priyanshubhartistm)! -
feat(payments): add per-plan event rate limits and retention

### Patch Changes

- [#1009](#1009)
[`ad8c5c4`](ad8c5c4)
Thanks [@chappie-daemon](https://github.com/chappie-daemon)! - build:
pin the node base image in every file that names one

`Dockerfile` pinned `node:24.22.1-alpine` by digest, but
`Dockerfile.railwayapp`, `Dockerfile.test`, `docker-compose.yml` and
`test/integration/docker-compose.yml` still said `node:24-alpine`. The
relay image, the CI image, the Railway image and both migration
containers could each start from a different base, and a floating tag
moves under a release — so the same commit built twice could run
different node code without a change saying so.

All five now carry the same tag and digest, and a unit test holds them
there: it fails if any reference loses its digest, and it fails if two
different references appear.

- [#1010](#1010)
[`fa54cb0`](fa54cb0)
Thanks [@chappie-daemon](https://github.com/chappie-daemon)! -
fix(settings): state that rate-limit periods are milliseconds and reject
a period that is not one

Every shipped limit counts in milliseconds — `1000`, `60000`, `900000`,
`3600000` — but nothing said so. `RateLimit.period` is a bare `number`,
so an operator writing `period: 60` for a minute got a 60 ms window —
and because `rate` is hits per window, that is a limit a thousand times
**looser** than intended, honoured without complaint, and caught by
nothing.

The unit is now stated on `RateLimit` and on every `rateLimits` block in
`resources/default-settings.yaml`, and `validateRateLimitPeriods`
rejects what cannot be a count of milliseconds: a fraction, a string, a
non-number, or anything below one millisecond. A whole number is not
enough to tell 60 from 60000, which is why the unit is documented where
it is set.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants