-
Notifications
You must be signed in to change notification settings - Fork 535
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Install with frozen-lockfile in routerlicious's docker build #23558
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Copilot reviewed 4 out of 23 changed files in this pull request and generated no comments.
Files not reviewed (19)
- server/routerlicious/Dockerfile: Language not supported
- server/routerlicious/package.json: Language not supported
- server/routerlicious/packages/gitresources/package.json: Language not supported
- server/routerlicious/packages/kafka-orderer/package.json: Language not supported
- server/routerlicious/packages/lambdas-driver/package.json: Language not supported
- server/routerlicious/packages/lambdas/package.json: Language not supported
- server/routerlicious/packages/local-server/package.json: Language not supported
- server/routerlicious/packages/memory-orderer/package.json: Language not supported
- server/routerlicious/packages/protocol-base/package.json: Language not supported
- server/routerlicious/packages/routerlicious-base/package.json: Language not supported
- server/routerlicious/packages/routerlicious/package.json: Language not supported
- server/routerlicious/packages/services-client/package.json: Language not supported
- server/routerlicious/packages/services-core/package.json: Language not supported
- server/routerlicious/packages/services-ordering-kafkanode/package.json: Language not supported
- server/routerlicious/packages/services-ordering-rdkafka/package.json: Language not supported
- server/routerlicious/packages/services-ordering-zookeeper/package.json: Language not supported
- server/routerlicious/packages/services-shared/package.json: Language not supported
- server/routerlicious/packages/services-telemetry/package.json: Language not supported
- server/routerlicious/packages/services-utils/package.json: Language not supported
the dep/typetest updates here get kind of involved. I'm open to splitting those to a precursor PR if reviewer would like. |
@@ -83,6 +83,8 @@ | |||
} | |||
}, | |||
"typeValidation": { | |||
"broken": {} | |||
"broken": {}, | |||
"disabled": true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This package has a bogus main
and types
entry: it has no actual index.ts
. Typetests using the previous build setup happened to be OK with this, but flub is not. Thus I have disabled them since the package has no API surface anyway.
It seems like if we want to publish this package, we should probably be exposing a script under bin
or something to run routerlicious, but going to consider that out of scope for this change...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. Maybe a (type-tests) entrypoint for each lambda would be an alternative, but with this being just a reference implementation, I'm not sure even that is necessary.
@@ -55,7 +56,7 @@ | |||
"stop": "docker compose down", | |||
"stop:full": "docker compose down -v", | |||
"test": "pnpm run -r --no-sort --stream --no-bail test", | |||
"test:copyresults": "copyfiles --exclude \"**/node_modules/**\" \"**/nyc/**\" nyc", | |||
"test:copyresults": "copyfiles --exclude \"**/node_modules/**\" \"packages/**/nyc/**\" nyc", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CI failed with strange issues here, and when I was debugging copyresults
locally I realized that the input glob here can match files written to output. Not sure exactly how that manifests in CI not finding results files, but given copyfiles looks to be highly parallelized, it seemed worth a shot to just make this change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This didn't fix the issue, but on further investigation I also noticed that we were reporting coverage on everything in the server directory including node_module dependencies. Adding some reasonable configurations that resemble the package root seems to have fixed this in latest build (hopefully it's not a flaky thing that reoccurs).
Hitting a limit like this while changing deps makes some vague amount of sense; I believe the newer version of flub has a heavier footprint. I do know at some point I fixed an issue with coverage caused by OOM issues merging reports when not using the merge-async option, so it seems plausible to me this pushed something in the report writing over the edge on CI machines.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any ideas why there would be any nyc directories (or src/lib/dist ones) outside packages/ ? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The docker image reference needs to be fixed, the rest looks good.
After this is merged, I'll spend a bit of time deploying the new docker images to our internal cluster so e2e tests can validate that everything looks correct there.
@@ -5,7 +5,22 @@ | |||
|
|||
# Use a direct sha256 hash to ensure we are always using the same version of the base image. | |||
# This avoids throttling issues with Docker Hub by using an image baked into the pipeline build image. | |||
FROM node:18.20.5-bookworm-slim@sha256:c4a278056a0f79abf472d912bbf5af6c874126ae450faad9df52069e9ad78335 AS base | |||
FROM node:18.17.1-buster-slim@sha256:cb2a746612c2564d3bd0f871174618337af9d0f4d895df6a623fd7a69ca6e5bd AS runnerbase |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FROM node:18.17.1-buster-slim@sha256:cb2a746612c2564d3bd0f871174618337af9d0f4d895df6a623fd7a69ca6e5bd AS runnerbase | |
FROM node:18.20.5-bookworm-slim@sha256:c4a278056a0f79abf472d912bbf5af6c874126ae450faad9df52069e9ad78335 AS runnerbase |
@@ -55,7 +56,7 @@ | |||
"stop": "docker compose down", | |||
"stop:full": "docker compose down -v", | |||
"test": "pnpm run -r --no-sort --stream --no-bail test", | |||
"test:copyresults": "copyfiles --exclude \"**/node_modules/**\" \"**/nyc/**\" nyc", | |||
"test:copyresults": "copyfiles --exclude \"**/node_modules/**\" \"packages/**/nyc/**\" nyc", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any ideas why there would be any nyc directories (or src/lib/dist ones) outside packages/ ? 🤔
@@ -83,6 +83,8 @@ | |||
} | |||
}, | |||
"typeValidation": { | |||
"broken": {} | |||
"broken": {}, | |||
"disabled": true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. Maybe a (type-tests) entrypoint for each lambda would be an alternative, but with this being just a reference implementation, I'm not sure even that is necessary.
Oh, also, a nice follow-up item at some point would be to use the same pnpm overrides we use in the root of the repo, in all the server pnpm workspaces, to get rid of all the aws dependencies that oclif brings in but we don't use. |
Description
Adjusts routerlicious's docker build to allow it to install with a frozen lockfile.
See #23535 for some additional context.