ci(github): Revert to running funTests in a GitHub action container

[sschuberth]

Please ensure that your pull request adheres to our contribution guidelines. Thank you!

[mnonnenmacher]

Different jobs run on different machines, so you would have to publish the image somewhere. I think publishing PR builds next to the official builds in the registry is problematic, so I don't have a good idea where else they could be published. I was hoping the local registry could be a soluation, but that's also bound to the lifetime of a job, not a workflow.
The official docs have this solution, but it also doesn't work with container jobs: https://docs.docker.com/build/ci/github-actions/share-image-jobs/

[sschuberth]

I think publishing PR builds next to the official builds in the registry is problematic

Why? Wouldn't it be ok if we tagged them uniquely and removed them after the PR build again?

[mnonnenmacher]

I guess I could live with that, even though I don't like those builds to appear when someone is looking at the packages in the GitHub UI. However, making sure that the image gets deleted even if some other steps fail might require implementing a custom action, I think composite actions don't support cleanup steps.
Another question is that of performance, of course the container job syntax is nicer than what we currently have, but it would have to be tested how uploading the image to the registry and then downloading it again compares to the current implementation.

[sschuberth]

I think composite actions don't support cleanup steps.

Wouldn't something like if: ${{ always() }} work, like we have it in static-analysis.yml?

Another question is that of performance, of course the container job syntax is nicer than what we currently have

I agree that performance matters, but this is not only about syntactic sugar. It also implicitly fixes the issue of restoring the unified diff for test failures, as environment variables get properly forwarded. Solving that problem led me to first look into why it worked before (with using container).

[mnonnenmacher]

I think composite actions don't support cleanup steps.

Wouldn't something like if: ${{ always() }} work, like we have it in static-analysis.yml?

If that guarantees that the step is always executed that should be fine.

Another question is that of performance, of course the container job syntax is nicer than what we currently have

I agree that performance matters, but this is not only about syntactic sugar. It also implicitly fixes the issue of restoring the unified diff for test failures, as environment variables get properly forwarded. Solving that problem led me to first look into why it worked before (with using container).

Forwarding the kotest variable to Docker would also be trivial, so I would give performance the priority here.

[mnonnenmacher]

I think you have to use ${{ github.run_id }} or maybe ${{ GITHUB_RUN_ID }} or $GITHUB_RUN_ID, this page says those variables are not available from the env context, but it does not give good examples: https://docs.github.com/de/actions/learn-github-actions/variables#default-environment-variables

[sschuberth]

The approaches tried out here do not work because

• only whole jobs, not steps of a job, can run in containers, which means the container needs to be created in another job, and the only way to pass images between jobs would be via a registry, but GitHub does not allow to publish ORT's registry from PRs / forks.
• uses pulls images at the start of a workflow, not only when it's needed, so there is no way to create the actual image beforehand.