Add test workflows

[valentin-seitz]

This PR does some things:

• adopt the dockerfile to work on ALL machines by specifing the host uid upon building time
• fetches the tutorial ref before trying to check that out (checkout-action doesnt do it)
• splits the testsuites runs into manual and reusable triggering
• introduce caching via GHA cache backend

[MakisH]

A few suggestions, mostly on documentation. The main aspect I am worried about is the UID/GID hard-coding.

Caching seems to work locally. Running the same test case twice, I get:

First time:

./tools/tests [add-test-workflows]$ python3 ./systemtests.py --suites=fenics_test
Using log-level: INFO
INFO: About to run the following systemtest in the directory /home/gc/repos/precice/tutorials/runs:
 [Flow over heated plate (fluid-openfoam, solid-fenics)]
INFO: Started running Flow over heated plate (fluid-openfoam, solid-fenics),  0/1
INFO: Running Flow over heated plate (fluid-openfoam, solid-fenics) took 1524.1612270610058 seconds
INFO: Success running Flow over heated plate (fluid-openfoam, solid-fenics)
+---------------------------------------------------------+---------+-------------------+-----------------+-----------------------+
| systemtest                                              | success | building time [s] | solver time [s] | fieldcompare time [s] |
+---------------------------------------------------------+---------+-------------------+-----------------+-----------------------+
| Flow over heated plate (fluid-openfoam, solid-fenics)   |    1    |      1272.33      |     157.36      |         92.69         |
+---------------------------------------------------------+---------+-------------------+-----------------+-----------------------+

Second time:

./tools/tests [add-test-workflows]$ python3 ./systemtests.py --suites=fenics_test
Using log-level: INFO
INFO: About to run the following systemtest in the directory /home/gc/repos/precice/tutorials/runs:
 [Flow over heated plate (fluid-openfoam, solid-fenics)]
INFO: Started running Flow over heated plate (fluid-openfoam, solid-fenics),  0/1
INFO: Running Flow over heated plate (fluid-openfoam, solid-fenics) took 178.49133943999186 seconds
INFO: Success running Flow over heated plate (fluid-openfoam, solid-fenics)
+---------------------------------------------------------+---------+-------------------+-----------------+-----------------------+
| systemtest                                              | success | building time [s] | solver time [s] | fieldcompare time [s] |
+---------------------------------------------------------+---------+-------------------+-----------------+-----------------------+
| Flow over heated plate (fluid-openfoam, solid-fenics)   |    1    |       1.64        |     161.08      |         14.06         |
+---------------------------------------------------------+---------+-------------------+-----------------+-----------------------+

This is also reflected in the ./runs/<id>/stdout.log file, where I see CACHED in all layers before the actual solver execution.

On GitHub Actions, while the cache is updated, (see the versions next to each name), we do not hit it, so the jobs do take a long time to run (rebuilding the images). @valentin-seitz could you please post a link to the bug you mentioned?

[valentin-seitz]

A few suggestions, mostly on documentation. The main aspect I am worried about is the UID/GID hard-coding.

Caching seems to work locally. Running the same test case twice, I get:

First time:

./tools/tests [add-test-workflows]$ python3 ./systemtests.py --suites=fenics_test
Using log-level: INFO
INFO: About to run the following systemtest in the directory /home/gc/repos/precice/tutorials/runs:
 [Flow over heated plate (fluid-openfoam, solid-fenics)]
INFO: Started running Flow over heated plate (fluid-openfoam, solid-fenics),  0/1
INFO: Running Flow over heated plate (fluid-openfoam, solid-fenics) took 1524.1612270610058 seconds
INFO: Success running Flow over heated plate (fluid-openfoam, solid-fenics)
+---------------------------------------------------------+---------+-------------------+-----------------+-----------------------+
| systemtest                                              | success | building time [s] | solver time [s] | fieldcompare time [s] |
+---------------------------------------------------------+---------+-------------------+-----------------+-----------------------+
| Flow over heated plate (fluid-openfoam, solid-fenics)   |    1    |      1272.33      |     157.36      |         92.69         |
+---------------------------------------------------------+---------+-------------------+-----------------+-----------------------+

Second time:

./tools/tests [add-test-workflows]$ python3 ./systemtests.py --suites=fenics_test
Using log-level: INFO
INFO: About to run the following systemtest in the directory /home/gc/repos/precice/tutorials/runs:
 [Flow over heated plate (fluid-openfoam, solid-fenics)]
INFO: Started running Flow over heated plate (fluid-openfoam, solid-fenics),  0/1
INFO: Running Flow over heated plate (fluid-openfoam, solid-fenics) took 178.49133943999186 seconds
INFO: Success running Flow over heated plate (fluid-openfoam, solid-fenics)
+---------------------------------------------------------+---------+-------------------+-----------------+-----------------------+
| systemtest                                              | success | building time [s] | solver time [s] | fieldcompare time [s] |
+---------------------------------------------------------+---------+-------------------+-----------------+-----------------------+
| Flow over heated plate (fluid-openfoam, solid-fenics)   |    1    |       1.64        |     161.08      |         14.06         |
+---------------------------------------------------------+---------+-------------------+-----------------+-----------------------+

This is also reflected in the ./runs/<id>/stdout.log file, where I see CACHED in all layers before the actual solver execution.

On GitHub Actions, while the cache is updated, (see the versions next to each name), we do not hit it, so the jobs do take a long time to run (rebuilding the images). @valentin-seitz could you please post a link to the bug you mentioned?

I think this issues also describes our problem quite well:
docker/build-push-action#829