MRChemSoft / mrchem

MultiResolution Chemistry
GNU Lesser General Public License v3.0
27 stars 21 forks source link

Add container build workflow #393

Closed stigrj closed 2 years ago

stigrj commented 2 years ago
codecov[bot] commented 2 years ago

Codecov Report

Merging #393 (a533cc1) into master (338ffc6) will not change coverage. The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master     #393   +/-   ##
=======================================
  Coverage   69.39%   69.39%           
=======================================
  Files         179      179           
  Lines       14235    14235           
=======================================
  Hits         9879     9879           
  Misses       4356     4356           

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 338ffc6...a533cc1. Read the comment docs.

stigrj commented 2 years ago

Hmm, currently it seems hard to successfully deploy two containers in the same workflow when testing in https://github.com/stigrj/ghcr_sandbox. It finally succeeded on attempt 5, consistent with ~50% success rate per deployment, which is also reported here: https://github.com/docker/buildx/issues/834. Seems to have been resolved, but I'm not sure how to incorporate the solution here? Suggestions @robertodr ?

stigrj commented 2 years ago

How much information do you think we should keep in the package name?

I guess the OS is irrelevant here and can be omitted, but the API of the MPI library matters since you need a compatible lib on host when running. This info i available in the metadata, though, so only strictly necessary if we plan to build for several libs/versions at the same time.

robertodr commented 2 years ago

Hmm, currently it seems hard to successfully deploy two containers in the same workflow when testing in https://github.com/stigrj/ghcr_sandbox. It finally succeeded on attempt 5, consistent with ~50% success rate per deployment, which is also reported here: docker/buildx#834. Seems to have been resolved, but I'm not sure how to incorporate the solution here? Suggestions @robertodr ?

I did not experience this when trying to deploy the dalton/lsdalton, so I am not sure I can really be of help here. It will take some time to understand how to translate the fix for Docker to Singularity...

robertodr commented 2 years ago

How much information do you think we should keep in the package name?

  • mrchem-mpi
  • mrchem-openmpi
  • mrchem-openmpi4.0
  • mrchem-openmpi4.0.5
  • mrchem-ubuntu20.04-openmpi4.0.5

I guess the OS is irrelevant here and can be omitted, but the API of the MPI library matters since you need a compatible lib on host when running. This info i available in the metadata, though, so only strictly necessary if we plan to build for several libs/versions at the same time.

I think I like version 3 above, since with patch versions the API should not change.

stigrj commented 2 years ago

Not even the same error message on all the failed deployments.

Sometimes

FATAL:   Unable to push image to oci registry: unable to push: failed to copy: failed to do request: Put "https://ghcr.io/v2/***/ghcr_sandbox/hello_world-vol1/blobs/upload/533290ca-c5c7-4f38-89e7-139a32ce1f93?digest=sha256%3A82f1e5b2d5e8c44a4c341949bb7d9ca487154b7b40452ce82b3705f5e83f8cfe": write tcp 172.18.0.2:37392->140.82.112.34:443: write: connection reset by peer
Error: Process completed with exit code 255.

other times

FATAL:   Unable to push image to oci registry: unable to push: failed to copy: failed to do request: Put "https://ghcr.io/v2/***/ghcr_sandbox/hello_world-vol2/blobs/upload/384c4f79-01e6-4afa-92e0-9099f6e78873?digest=sha256%3Abe619f63efdc33799ccbf84a1410fab56f1f36551428ec248ce68cf024edb30d": unexpected EOF
Error: Process completed with exit code 255.