Test ACTSTracking Processors Using GitHub Actions

[kkrizka]

This depends on #1. Marking as draft until it is merged. However the code/methology is ready for review.

Implements automated testing of different Processors in the built images. This ensures that all packages included in a release are working together in a consistent manner.

This PR only tests the ACTSTracking package. However the framework proposed here can be extended to other packages.

The new workflow is as follows:

1. Build image (as in Automatically Build Image Using GitHub Actions #1)
2. Generate a small number of events (10 single muons for now)
3. Run Marlin steering files on 2.

Image Building

The images are built as in #1. The only addition is uploading an additional label for the final image with the git SHA: mucoll-ilc-framework:${{github.sha}}-centos8. This is to have a uniquely identifiable image for each run of a workflow to be used in subsequent jobs. DockerHub is used as storage to share the images between jobs. A possible downside is pollution of the DockerHub repository.

Event Generation

This stage runs ddsim on sim steering files that are stored in the test/ directory. For now this is 10 events of single muons. However more configurations can be matrixed into this job.

Events are transferred between sim and test jobs using GitHub Action caching mechanism. The hash of the sim steering file is used as simulation key. This saves time by only running simulation only when changes are detected in the steering file. However it is not sensitive to changes in the DD4hep and GEANT libraries.

Running Marlin

Runs Marling on several steering files provided by individual packages. The location of steering files is matrixed into the job. This allows to scale this stage to multiple steering files and run the jobs in parallel.

[madbaron]

Apart from this being relatively old/outdated, I think this is great and we should set up these kind tests systematically.
I wonder though if this is the right place for this test to live in. Shouldn't it rather go to the ACTSTracking repo?

[kkrizka]

Apart from this being relatively old/outdated, I think this is great and we should set up these kind tests systematically. I wonder though if this is the right place for this test to live in. Shouldn't it rather go to the ACTSTracking repo?

Potentially both? This was moving towards having an encompassing set of tests for everything that we want to check when making a release.