Separate github workflows by container

[m-goggins]

PULL REQUEST

Summary

Breaks out the test.yaml file for separate test workflows for each container. The tests are triggered when there are changes to the container and its dependencies (except orchestration, which is run whenever there are any changes). See table for

Related Issue

Fixes #1951

Additional Information

Anything else the review team should know?

Checklist

• If this code affects the other scrum team, have they been notified? (In Slack, as reviewers, etc.)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.01%. Comparing base (445e545) to head (9f0e241).
Report is 4 commits behind head on main.

❗ Current head 9f0e241 differs from pull request most recent head fd46360

Please upload reports for the commit fd46360 to get more accurate results.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1965   +/-   ##
=======================================
  Coverage   97.01%   97.01%           
=======================================
  Files          48       48           
  Lines        3053     3053           
=======================================
  Hits         2962     2962           
  Misses         91       91           

Flag	Coverage Δ
unit-tests	97.01% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

[robertandremitchell]

Broadly LGTM as well. Rob, if I had to guess, the services where we use build-args are those where we're accessing something from a licensed secret (i.e. we only use them for SMARTY creds or URLs for other services we've deployed). I think this is a little bit unsatisfying as an answer because in something like the Orchestration service, we have database login information set as an environment variable, and that info clearly has just as much of a right to be protected as a SMARTY cred. I think what this might just come down to is that we used SMARTY and referential URLs back when we had all this deployed in Azure with LAC, and so secrets + Keyvault management was something we just sort of got accustomed to setting up. So I think it might honestly just be an evolution of our product that we switched from build args and secrets to environment variables. I'm okay to give this an approval, but will wait until we get any more discussion or input on the build args point.

ah, yeah, that makes sense. I thought they were there for orchestration's sake, which would have meant needing them for all services.

[DanPaseltiner]

LGTM. Thank you for putting this together. I think this will be a huge improvement. Couple comments below that I'm happy to discuss further, but nothing that is blocking.