Remove the unmaintained Batect in favor of using a GitHub action container

[sschuberth]

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

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (46de195) 67.16% compared to head (dbec174) 67.16%.
Report is 4 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##               main    #7853   +/-   ##
=========================================
  Coverage     67.16%   67.16%           
  Complexity     2049     2049           
=========================================
  Files           357      357           
  Lines         17158    17158           
  Branches       2461     2461           
=========================================
  Hits          11525    11525           
  Misses         4611     4611           
  Partials       1022     1022           

Flag	Coverage Δ
funTest-docker	66.25% <ø> (ø)
funTest-non-docker	33.96% <ø> (ø)
test	36.98% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[sschuberth]

In my comparisons, this new approach reduces the funTest-docker runtime by at least ~10 minutes.

[mnonnenmacher]

Commit message: "Docherfile" -> "Dockerfile"

The downside is that Dockerfile changes and e.g. package manager changes depending on it cannot be performed in the same commit / PR as the image first needs to get published.

Doesn't this introduce a serious issue if e.g. a tool version in Docker is upgraded and any test failures caused by this only appear in a random other PR later on? This probably also creates the risk that we make broken releases.

I thought with the new setup building the Docker image is a lot faster, as most of the images can be reused from the registry, and that only Batect was blocking us from using the registry. E.g. if the Python version is upgraded only the Python image needs to be rebuilt, and if nothing is changed in Docker the build should be very fast?

[sschuberth]

Doesn't this introduce a serious issue if e.g. a tool version in Docker is upgraded and any test failures caused by this only appear in a random other PR later on?

Yes, that's a valid point. To solve this, we should probably do something like this in the PR:

1. Pull the current snapshot image.
2. (Re-)build the Docker image from source on the worker node, which should be fast due to stage image / layer caching, if not a lot has changed in the Dockerfile itself.
3. Run functional tests against the local Docker image.
4. Push the Docker image as the new snapshot if everything succeeded.

[sschuberth]

Batect was blocking us from using the registry.

Not that it matters now anymore as Batect became unmaintained, but Batect was not blocking us from using the registry. Batect just made it hard / impossible to benefit from stage image / layer caching in conjunction with the docker/build-push-action.

E.g. if the Python version is upgraded only the Python image needs to be rebuilt, and if nothing is changed in Docker the build should be very fast?

That's my understanding as well, but I haven't verified it.

[sschuberth]

@heliocastro please don't force-push to branches owned by others without discussing this first! Not even if it's a simple rebase.

[heliocastro]

This solution is better since we are not anymore relying on two different codebases for Docker.
With the introduction of multiarch, debugging test issues will be a not be easy task, as now images from legacy and main are really disconnected.

[heliocastro]

@heliocastro please don't force-push to branches owned by others without discussing this first! Not even if it's a simple rebase.

Sorry for that. I didn't think that would be an issue.

[sschuberth]

I didn't think that would be an issue.

It breaks my checks which of my local branches are not in-sync with the remotes.

[mnonnenmacher]

As discussed on Slack I am approving that now despite my concerns as @heliocastro committed to making another PR that runs the functional tests with an image that matches the PR again.