Refactoring the container build process in Github Actions for improved reliability

[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 42.37%. Comparing base (46529b9) to head (eec3176).
⚠️ Report is 3 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #659   +/-   ##
=======================================
  Coverage   42.37%   42.37%           
=======================================
  Files          30       30           
  Lines        2834     2834           
=======================================
  Hits         1201     1201           
  Misses       1633     1633           

Flag	Coverage Δ
hewr	37.97% <ø> (ø)
pipelines	37.33% <ø> (ø)
pyrenew_hew	62.29% <ø> (ø)

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

[damonbayer]

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

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

@jkislin What do you think of this?

[jkislin]

@jkislin I think with these simplifications we can just remove the docker_build_and_push.sh script and use the official action, no? docker/build-push-action
Might resolve the manifest issues and should in general be more robust

@jkislin What do you think of this?

It's possible that would help, I am noticing that there's either inappropriate (or we just don't understand exactly) redirect behavior when specifying image tags on ghcr.io.

Any tag I supply directs here. There's a "latest" meta-tag that applies even if the image pushed wasn't tagged "latest".

I'm now also getting this error on the pool itself. I'm going to see if making "latest" the actual "latest" changes things.

[jkislin]

I've refactored for the build-and-push action, and we can toggle cacheing via commenting/uncommenting the final two lines.

[dylanhmorris]

Thanks, @jkislin! Should be good to go with deletion of old shell script

[dylanhmorris]

LGTM!