-
Notifications
You must be signed in to change notification settings - Fork 7
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
Reduce-docker-buildtime #1970
base: main
Are you sure you want to change the base?
Reduce-docker-buildtime #1970
Conversation
package.json
Outdated
@@ -245,6 +245,7 @@ | |||
] | |||
}, | |||
"devDependencies": { | |||
"turbo": "^1.9.6", |
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.
are you using turbo somewhere? don't see it
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.
Ah no,
left over from taking a peek at https://turbo.build/
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.
yeah it looks cool, our JS build tooling is definitely behind the ecosystem
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.
They have some content on getting it added in to existing work https://turbo.build/repo/docs/getting-started/existing-monorepo
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.
I was able to get the frontend to build & cache easily enough.
Would love to see some of this stuff implemented!
I'm not sure exactly what the deal with testingonly is, but the node stuff is different for frontend and backend if that's the depencies you are referring to |
The unnecessary abstractions pains me, like these are what docker files are for. node-gyp & yarn install are run independently 4 times, each on a base container that is inherently large. From what I can tell the only major differences are the frontend and backend worker & testingonly make use of the backend. Through caching we can define two images, (or even narrow down to further specifics) "docker:reset": "./bin/reset-all", ->
#!/bin/bash
yarn docker:stop --volumes
yarn docker:deps -->
yarn docker:db:migrate
yarn docker:db:seed
yarn docker:stop
"docker:deps": "docker compose run --rm backend yarn global add node-gyp && docker compose run --rm backend yarn install && docker compose run --rm frontend yarn global add node-gyp && docker compose run --rm frontend yarn install && docker compose run --rm testingonly yarn global add node-gyp && docker compose run --rm testingonly yarn install",
"docker:db:migrate": "docker compose run --rm backend node_modules/.bin/sequelize db:migrate && yarn docker:ldm",
-->
"ldm": "tsx ./src/tools/logicalDataModelCLI.ts",
"docker:db:seed": "docker compose run --rm backend yarn db:seed",
-->
"db:seed": "node_modules/.bin/sequelize db:seed:all",
|
Testing only exposes an api to allow a test to reset the DB to a clean seeded db or from an e2e test it can query in to look stuff up or make changes. It was placed in it own app to force a hard separation from it and the published site. That way there is zero chance that someone could maliciously wipe, modify, or access production data. |
Could also be helpful to look into using buildpack to output the OCI image for ci/cd & local dev. This would do the equivalent of building optimized images and would mirror the cloud.gov experience a bit more. |
I think this is some of the confusion and what adds to the overall slowness, there are abstractions and components that need to be rebuilt through the yarn commands. We opt to rebuild all the things, bur really we should create a process that better supports options to independently run CI task or reporting requirement. |
Description of change
This looks to revise current practices to align with good container habits.
Docker Hygiene
- Switch to OWASP - (Bare container)[https://www.zaproxy.org/docs/docker/about/#bare]
- Also update image repo to gh from docker
- Build frontend into node-alpine image
- Build backend into node-slim (something broke when trying to use Alpine image
Things that Slow the builds
How to test
[things we should work towards]
Build a unified method for platform contributions (or in a lighter sense eliminate the confusion of works on my machine), there's some great tooling out there like .devcontainers.
Issue(s)
Checklists
Every PR
Before merging to main
Production Deploy
After merge/deploy