Adding workflow for tests

[jpodivin]

Unit tests, integration tests and database tests are now executed as github action. The workflow is, intentionally, very similar to what developer would have to use. And it should stay that way if possible.

[gemini-code-assist]

Note

Gemini is unable to generate a summary for this pull request due to the file types involved not being currently supported.

[softwarefactory-project-zuul]

Build failed.
https://softwarefactory-project.io/zuul/t/packit-service/buildset/fa536115305d4af59c8ec8b2634fc851

❌ pre-commit FAILURE in 1m 47s
✔️ packit-service-tests SUCCESS in 3m 17s

[softwarefactory-project-zuul]

Build succeeded.
https://softwarefactory-project.io/zuul/t/packit-service/buildset/f442fa059f9a467ea8c3b686457a6747

✔️ pre-commit SUCCESS in 1m 49s
✔️ packit-service-tests SUCCESS in 3m 22s

[softwarefactory-project-zuul]

Build succeeded.
https://softwarefactory-project.io/zuul/t/packit-service/buildset/7697240ac4d64c3e9e05add6ac3e2bf0

✔️ pre-commit SUCCESS in 1m 45s
✔️ packit-service-tests SUCCESS in 3m 21s

[softwarefactory-project-zuul]

Build succeeded.
https://softwarefactory-project.io/zuul/t/packit-service/buildset/99c74b0b298d4c32b82f3df760f41e5f

✔️ pre-commit SUCCESS in 1m 47s
✔️ packit-service-tests SUCCESS in 3m 13s

[softwarefactory-project-zuul]

Build succeeded.
https://softwarefactory-project.io/zuul/t/packit-service/buildset/c0595b93cb4f480792ce8212db2743a3

✔️ pre-commit SUCCESS in 1m 53s
✔️ packit-service-tests SUCCESS in 3m 54s

[softwarefactory-project-zuul]

Build succeeded.
https://softwarefactory-project.io/zuul/t/packit-service/buildset/da4de793277241baa57c28117ab3e312

✔️ pre-commit SUCCESS in 1m 49s
✔️ packit-service-tests SUCCESS in 3m 09s

[softwarefactory-project-zuul]

Build succeeded.
https://softwarefactory-project.io/zuul/t/packit-service/buildset/7d5e394dea9c4290bd3d615dc7458a7a

✔️ pre-commit SUCCESS in 1m 44s
✔️ packit-service-tests SUCCESS in 3m 13s

[softwarefactory-project-zuul]

Build succeeded.
https://softwarefactory-project.io/zuul/t/packit-service/buildset/9a1eb63e8884434aacc28d7244fa2b2f

✔️ pre-commit SUCCESS in 1m 46s
✔️ packit-service-tests SUCCESS in 3m 18s

[softwarefactory-project-zuul]

Build succeeded.
https://softwarefactory-project.io/zuul/t/packit-service/buildset/b6e4d649e4d648cca92e4bdcf5cd9a82

✔️ pre-commit SUCCESS in 1m 43s
✔️ packit-service-tests SUCCESS in 3m 32s

[softwarefactory-project-zuul]

Build succeeded.
https://softwarefactory-project.io/zuul/t/packit-service/buildset/42f5792895f5402cb7f81e6611d8fd52

✔️ pre-commit SUCCESS in 1m 46s
✔️ packit-service-tests SUCCESS in 3m 20s

[softwarefactory-project-zuul]

Build succeeded.
https://softwarefactory-project.io/zuul/t/packit-service/buildset/06985ba99bdd41dc820558cb0403b893

✔️ pre-commit SUCCESS in 1m 43s
✔️ packit-service-tests SUCCESS in 3m 23s

[softwarefactory-project-zuul]

Build succeeded.
https://softwarefactory-project.io/zuul/t/packit-service/buildset/5657554f9c9a4ebc9936f41ffba75f91

✔️ pre-commit SUCCESS in 1m 50s
✔️ packit-service-tests SUCCESS in 3m 20s

[mfocko]

As per the discuss label:

1. This feels like further fragmentation of the CI setup Packit has (more specifically: pre-commit.ci, Zuul, Packit itself where it's feasible (all the way to the Testing Farm))

2. In a sense it feels unnecessary, e.g., make check-in-container is what Zuul basically does.

   • except for make check-db… that part was deemed low-priority and was waiting for migration to TF

3. If possible, I'd prefer utilising Testing Farm as has been proposed in ci(tmt): run the tests on Testing Farm #2443, but

   • the intention of aforementioned PR was to unify the testing CI across Packit, but it doesn't allow for reverse-dependency testing of Service itself, because of TFT-2521
   • there's been a considerable amount of work spent by @majamassarini on making the OpenShift setup “somewhat” work on Testing Farm; in the context of this PR we also discussed the possibility of using podman-compose on TF, which would probably require less effort to make it work in comparison to the OpenShift itself

4. I appreciate the Build Test Image step, it would definitely make sense to me to:

   • run it for PRs, if any of the files related to the image build get changed, i.e., any of the Containerfiles and (most likely all of) files/ subtree
   • run it as part of the merge queue all the time, though this suggestion will probably be the most problematic, as the setup, right now, depends on Zuul and merging is also managed via Zuul.

---

There's also a possibility of trying out the TF setup even if the rev-dep tests (from Packit and ogr) are not possible right now, making the make check-db work with TF and decide on the next steps later based on the outcome of this.

[softwarefactory-project-zuul]

Build succeeded.
https://softwarefactory-project.io/zuul/t/packit-service/buildset/3a842b1d32124b928f376b2b8deb2cb7

✔️ pre-commit SUCCESS in 1m 47s
✔️ packit-service-tests SUCCESS in 3m 17s

[jpodivin]

As per the discuss label:

1. This feels like further fragmentation of the CI setup Packit has (more specifically: pre-commit.ci, Zuul, Packit itself where it's feasible (all the way to the Testing Farm))

I agree. I would personally drop pre-commit ci. It is already duplicating what is in zuul and provides little additional value.

2. In a sense it feels unnecessary, e.g., `make check-in-container` is what Zuul basically does.
   
   * except for `make check-db`… that part was deemed low-priority and was waiting for migration to TF

I've dropped the tests already executed in zuul. But database tests should be executed somewhere. Leaving them out, will inevitably lead to issues being discovered in stage or production.

3. If possible, I'd prefer utilising Testing Farm as has been proposed in [ci(tmt): run the tests on Testing Farm #2443](https://github.com/packit/packit-service/pull/2443), but
   
   * the intention of aforementioned PR was to unify the testing CI across Packit, but it doesn't allow for reverse-dependency testing of Service itself, because of [TFT-2521](https://issues.redhat.com/browse/TFT-2521)
   * there's been a considerable amount of work spent by @majamassarini on making the OpenShift setup “somewhat” work on Testing Farm; in the context of this PR we also discussed the possibility of using `podman-compose` on TF, which would probably require less effort to make it work in comparison to the OpenShift itself

In github, running things in compose requires only a minimal effort. Until the testing is done in TF, which may not be for a while yet, the tests should be run somewhere.

4. I appreciate the _Build Test Image_ step, it would definitely make sense to me to:
   
   * run it for PRs, **if** any of the files related to the image build get changed, i.e., any of the `Containerfile`s and (most likely all of) `files/` subtree
   * run it as part of the merge queue **all the time**, though this suggestion will probably be the most problematic, as the setup, right now, depends on Zuul and merging is also managed via Zuul.

There's also a possibility of trying out the TF setup even if the rev-dep tests (from Packit and ogr) are not possible right now, making the make check-db work with TF and decide on the next steps later based on the outcome of this.

[majamassarini]

We discussed this approach at the arch meeting last week and decided to prioritize work to unblock tests on Testing Farm. Therefore, we will not approve this PR. The main reason is to avoid having yet another testing infrastructure to maintain. We hope we can enable these same tests soon enough on Testing Farm.

[jpodivin]

I understand. Closing PR.