Removing container build cacheing to assess build reliability without it

[jkislin]

Running tests. Will request review. It probably makes sense to leave the cache code commented in the script as we may change our mind again!

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 26.18%. Comparing base (f2d4094) to head (59f4059).
⚠️ Report is 7 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #659      +/-   ##
==========================================
- Coverage   26.21%   26.18%   -0.04%     
==========================================
  Files          26       26              
  Lines        2411     2414       +3     
==========================================
  Hits          632      632              
- Misses       1779     1782       +3     

Flag	Coverage Δ
hewr	30.07% <ø> (-0.04%)	⬇️
pipelines	3.07% <ø> (-0.01%)	⬇️
pyrenew_hew	63.18% <ø> (ø)

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

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[jkislin]

@dylanhmorris not sure what's going on with the format-suggest check, but otherwise, I removed the cacheing code and the container successfully builds and post to ghcr.io.

Let me know if there's a way I can help test the functionality of the container, or if that's even necessary given our automated tests. If not necessary, please feel free to review or provide feedback!

Thanks,
Jon

[dylanhmorris]

Let me know if there's a way I can help test the functionality of the container, or if that's even necessary given our automated tests. If not necessary, please feel free to review or provide feedback!

Thanks, @jkislin! I think the best way to test functionality before merging to try running a job in Azure with the jk-rm-cache version of the container via setup_job.py. Could you try that and report the results?

[jkislin]

Let me know if there's a way I can help test the functionality of the container, or if that's even necessary given our automated tests. If not necessary, please feel free to review or provide feedback!

Thanks, @jkislin! I think the best way to test functionality before merging to try running a job in Azure with the jk-rm-cache version of the container via setup_job.py. Could you try that and report the results?

I am still getting a Manifest unknown error.

I will investigate more tomorrow.

[dylanhmorris]

@jkislin I think with these simplifications we can just remove the docker_build_and_push.sh script and use the official action, no? https://github.com/docker/build-push-action

Might resolve the manifest issues and should in general be more robust