search

NNPDF / pineappl

PineAPPL is not an extension of APPLgrid
https://nnpdf.github.io/pineappl/
GNU General Public License v3.0
12 stars 3 forks source link

Attempt to use a custom container for CI #208

Closed cschwan closed 1 year ago

cschwan commented 1 year ago

Use a custom container to cut down the time of the Rust and CAPI action.

cschwan commented 1 year ago

Pretty good!

alecandido commented 1 year ago

In case you care, all the support for the CI of the NNPDF projects is currently collected in the repo https://github.com/NNPDF/workflows (other than NNPDF/nnpdf itself, that always had a separate management, people-wise and therefore tools-wise).

In particular, the Containerfiles for the containers we are using are all in https://github.com/NNPDF/workflows/tree/v2/containers

The containers themselves belong to the NNPDF org, and they are linked to the workflows repo: https://github.com/orgs/NNPDF/packages?repo_name=workflows

Btw, there is already one container with just LHAPDF installed, together with the baseline of common PDF sets. But there is no installation of Rust available, so keep using your own.

cschwan commented 1 year ago

In case you care, all the support for the CI of the NNPDF projects is currently collected in the repo https://github.com/NNPDF/workflows (other than NNPDF/nnpdf itself, that always had a separate management, people-wise and therefore tools-wise).

In particular, the Containerfiles for the containers we are using are all in https://github.com/NNPDF/workflows/tree/v2/containers

The containers themselves belong to the NNPDF org, and they are linked to the workflows repo: https://github.com/orgs/NNPDF/packages?repo_name=workflows

Btw, there is already one container with just LHAPDF installed, together with the baseline of common PDF sets. But there is no installation of Rust available, so keep using your own.

In that case I think it makes sense to migrate it there!

alecandido commented 1 year ago

In that case I think it makes sense to migrate it there!

To keep things as plain as possible, I'd suggest completing it here and merge, then migrate in a separate PR.

In any case, thanks a lot for this, this will be useful also for other possible uses, not only the CI!

cschwan commented 1 year ago

Something I don't completely understand yet is which files github needs and therefore which files in the container I can delete. I understand that when I chroot into the container I only have the files in the container, obviously, but I think github doesn't exactly do that and needs fewer files. The fact that I still have to specify runs-on: ubuntu-latest probably means that some files of that system are available...

alecandido commented 1 year ago

You're definitely looking at the process from a too low-level perspective. Usually you just talk of container runtimes, and forget about the chroot part (even though is definitely useful to remember with in general, if you are concerned about privileges escalation and security).

You do not need any file specifically in the container, it can also be almost empty, for as long as it can run a shell (I believe that's the only program executed).

The reason why you have to specify runs on: is that they have to allocate a virtual machine, and you are billed according to the virtual machine that you ask for. Moreover, I'm not sure whether they are supported, but in principle you might also want to run a Windows container, and for that you need a Windows virtual machine.