Skip to content
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

Open
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

Abe27342
Copy link
Contributor

Description

Adjusts routerlicious's docker build to allow it to install with a frozen lockfile.

See #23535 for some additional context.

@Copilot Copilot bot review requested due to automatic review settings January 15, 2025 01:23

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
@github-actions github-actions bot added area: server Server related issues (routerlicious) base: main PRs targeted against main branch labels Jan 15, 2025
@github-actions github-actions bot added the area: build Build related issues label Jan 15, 2025
@Abe27342
Copy link
Contributor Author

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,
Copy link
Contributor Author

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...

Copy link
Contributor

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",
Copy link
Contributor Author

@Abe27342 Abe27342 Jan 15, 2025

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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/ ? 🤔

Copy link
Contributor

@alexvy86 alexvy86 left a 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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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",
Copy link
Contributor

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,
Copy link
Contributor

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.

@alexvy86
Copy link
Contributor

alexvy86 commented Jan 16, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: build Build related issues area: server Server related issues (routerlicious) base: main PRs targeted against main branch
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants