Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.85%. Comparing base (0971c41) to head (898ac23).
Report is 2 commits behind head on main.

@@            Coverage Diff             @@
##             main     #262      +/-   ##
==========================================
+ Coverage   97.82%   97.85%   +0.02%     
==========================================
  Files          33       33              
  Lines        1748     1770      +22     
==========================================
+ Hits         1710     1732      +22     
  Misses         38       38              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@ericbuckley After trying out the build-push-action in the smoke tests for the RL image (here), I'm still seeing it pull the python slim image every time. Perhaps I've implemented the build-push-action incorrectly, but from my understanding it doesn't cache the final image (only the build layers), which is potentially why it's pulling python slim every time?

In this iteration, I re-worked the RL to push to GHCR as rl-service:pr-$PR_NUMBER so that we don't run into conflicts with rl-service:latest when two builds happen simultaneously as you pointed out on the other PR. Thoughts?

I'm also happy to pair on this if you have time and some additional thoughts on the build-push-action tact.

@ericbuckley After trying out the build-push-action in the smoke tests for the RL image (here), I'm still seeing it pull the python slim image every time. Perhaps I've implemented the build-push-action incorrectly, but from my understanding it doesn't cache the final image (only the build layers), which is potentially why it's pulling python slim every time?

In this iteration, I re-worked the RL to push to GHCR as rl-service:pr-$PR_NUMBER so that we don't run into conflicts with rl-service:latest when two builds happen simultaneously as you pointed out on the other PR. Thoughts?

I'm also happy to pair on this if you have time and some additional thoughts on the build-push-action tact.

In the commit you shared it looked like the caching was happening in one job (build-rl-with-docker) and the execution in another (smoke_tests)? Do you know if gha caching is persisted across jobs and/or did you try it all as one job?

The rl-service:pr-$PR_NUMBER works as a solution as well, I think with that path we should think through a cleanup path though, as it will get quite large over time. That can be done in a second GH issue though. And I'm also around to pair this afternoon if you want.

gha caching does not persist across jobs. I forgot to mention that I tried both (caching and building in one job and separately) but neither seemed to do the trick.

I'll proceed with the rl-service:pr-$PR_NUMBER solution and write a follow up ticket to handle the clean up.

gha caching does not persist across jobs. I forgot to mention that I tried both (caching and building in one job and separately) but neither seemed to do the trick.

I'll proceed with the rl-service:pr-$PR_NUMBER solution and write a follow up ticket to handle the clean up.

@m-goggins thanks for all your experimentation here, testing is particularly tricky as we haven't run into a dockerhub authentication issue yet! Another option to consider, the work you did on the database services gets us more than halfway there (according to my count, we use 6 service images in every commit check and 4 rl-service images). I'm wondering, if maybe we just roll out the database service caching work you did and call it at that. Wait to see if anything breaks post Apr 1st and go from there.

I tried testing on this branch, but it looks like scheduled jobs only run on the default branch of a repo so I can't test until it's merged into main.

I set it to run at 12:01am on the 27th so assuming you're okay with merging, I can check to see if it worked tomorrow and re-adjust to the 1st if everything goes smoothly.

I tried testing on this branch, but it looks like scheduled jobs only run on the default branch of a repo so I can't test until it's merged into main.

I set it to run at 12:01am on the 27th so assuming you're okay with merging, I can check to see if it worked tomorrow and re-adjust to the 1st if everything goes smoothly.

Oh, I meant instead of changing the schedule, change the trigger. The below would have the workflow run on a PR that is trying to merge into main.

on:
  push:
    branches: [main]

Oh, yep! In that case, it has run successfully, here: https://github.com/CDCgov/RecordLinker/actions/runs/14065686730