Reduce-docker-buildtime

[kcirtapfromspace]

Description of change

This looks to revise current practices to align with good container habits.

Docker Hygiene

• Switches to lighter-weight docker images (where possible)
      - 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
• Reduce the variable sprawl
• Multistage builds to add layer caching
• docker-compose caching
• mount only what is necessary.
• change compose commands to v2 (docker-compose migrate)[https://docs.docker.com/compose/migrate/]

Things that Slow the builds

• Postcss complaints seemed to considerably delay or slow build time
• the abstraction of docker commands hides some of the innate inefficiencies. Downloading & Installing the same dependencies four times[ frontend, backend, worker, testingonly] doesn't help the cause for developers. It creates a situation where changing to someone else's branch can be a drag as you expect a ~20+ minute prep time.

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)

• https://ocio-jira.acf.hhs.gov/browse/TTAHUB-0

Checklists

Every PR

• Meets issue criteria
• JIRA ticket status updated
• Code is meaningfully tested
• Meets accessibility standards (WCAG 2.1 Levels A, AA)
• API Documentation updated
• Boundary diagram updated
• Logical Data Model updated
• Architectural Decision Records written for major infrastructure decisions
• UI review complete

Before merging to main

• OHS demo complete
• Ready to create production PR

Production Deploy

• Staging smoke test completed

After merge/deploy

• Update JIRA ticket status

[thewatermethod]

are you using turbo somewhere? don't see it

[kcirtapfromspace]

Ah no,
left over from taking a peek at https://turbo.build/

[thewatermethod]

yeah it looks cool, our JS build tooling is definitely behind the ecosystem

[kcirtapfromspace]

They have some content on getting it added in to existing work https://turbo.build/repo/docs/getting-started/existing-monorepo

[kcirtapfromspace]

I was able to get the frontend to build & cache easily enough.

#1973

[thewatermethod]

Would love to see some of this stuff implemented!

Downloading & Installing the same depedenciceise four times[ frontend, backend, worker, testingonly] doesn't help the cause for developers. It creates a situation where changin to someone elses branch can be a drag as you expect a ~20+ minute prep time.

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

[kcirtapfromspace]

Would love to see some of this stuff implemented!

Downloading & Installing the same depedenciceise four times[ frontend, backend, worker, testingonly] doesn't help the cause for developers. It creates a situation where changin to someone elses branch can be a drag as you expect a ~20+ minute prep time.

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",

[GarrettEHill]

Would love to see some of this stuff implemented!

Downloading & Installing the same depedenciceise four times[ frontend, backend, worker, testingonly] doesn't help the cause for developers. It creates a situation where changin to someone elses branch can be a drag as you expect a ~20+ minute prep time.

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

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.

[kcirtapfromspace]

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.

[kcirtapfromspace]

Would love to see some of this stuff implemented!

Downloading & Installing the same depedenciceise four times[ frontend, backend, worker, testingonly] doesn't help the cause for developers. It creates a situation where changin to someone elses branch can be a drag as you expect a ~20+ minute prep time.

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

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.

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.