Currently both the krill and rpki-deploy repos have main.yml files with lots of steps in them in order to use the krill-e2e-test. If these were to be packaged into a GitHub Actions Docker container action this could be defined once and referenced by both repo main.yml files, and lots of the installation work could be done once and the results baked into a hosted container image. This would be simpler to use, easier to maintain, faster to run and have frewer dependencies on the host O/S setup.
See branch gh-docker-action. At the present time it mostly works, but:
It will fail when it gets as far as invoking a Docker container to generate the Krill Python client library from the OpenAPI spec. as that requires starting a Docker container from within a Docker container which I do not think is possible with GitHub Actions, so would require invoking the code generator without Docker.
It fails building the python-rtrlib wrapper (see here). However, it would probably be best to build the Python dependencies that don't change as part of the Dockerfile and make them available to the Python venv via --system-site-packages (or skip a venv entirely as we're inside a Docker container).
Currently both the krill and rpki-deploy repos have
main.yml
files with lots of steps in them in order to use thekrill-e2e-test
. If these were to be packaged into a GitHub Actions Docker container action this could be defined once and referenced by both repomain.yml
files, and lots of the installation work could be done once and the results baked into a hosted container image. This would be simpler to use, easier to maintain, faster to run and have frewer dependencies on the host O/S setup.