Repository navigation
PACKIT-5037: Enable Packit CI - #627
Conversation
There was a problem hiding this comment.
Code Review
This pull request updates the Packit target environments to fedora-latest-stable and adds an encrypted GITLAB_CI_TOKEN to the Testing Farm configuration. The reviewer noted that the GITLAB_CI_TOKEN secret is incorrectly formatted as a list, which will cause Testing Farm to fail to parse the configuration or break the git clone command. It should be defined as a single string instead.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
3168d6f to
fd72f09
Compare
|
/packit test |
3c3c9ec to
ef9ef34
Compare
|
/packit test |
380ee68 to
595cbc3
Compare
9168d5a to
a093c17
Compare
|
/packit test |
77a84b1 to
8158442
Compare
lbarcziova
left a comment
There was a problem hiding this comment.
looks great, thanks a lot!
Signed-off-by: Matej Focko <mfocko@packit.dev>
After trying to run the pipeline, I've noticed that CentOS is missing podman-compose. After a brief chat with @TomasKorbar, it should be OK to run on the latest Fedora. Signed-off-by: Matej Focko <mfocko@packit.dev>
Tags have to be KV pairs. Signed-off-by: Matej Focko <mfocko@packit.dev>
Signed-off-by: Matej Focko <mfocko@packit.dev>
Looking at the docs, it appears that the only files that are guaranteed
to be persistent are saved within the $TMT_PLAN_DATA directory, therefore
move the prepped data there and move them back before the test starts.
Excerpt from the docs:
If you want to use the prepare step to generate data files needed for
testing during the execute step, move or copy them into
${TMT_PLAN_DATA} directory. Only files in this directory are
guaranteed to be preserved.
Signed-off-by: Matej Focko <mfocko@packit.dev>
These two are missing from the initial proposed tmt plan. Signed-off-by: Matej Focko <mfocko@packit.dev>
Wrap the test cases, so that it is easier to see which Jira tickets have failed the tests, instead of generic `test_case_‹index›`. Signed-off-by: Matej Focko <mfocko@packit.dev>
It is possible to propagate artifacts produced by the tests to the results of the tests. Tracing server needs to be running for running the tests, might as well collect the produced traces from it. It can be also helpful during the debugging as the produced logs may be interleaved (test cases are run asynchronously). Signed-off-by: Matej Focko <mfocko@packit.dev>
Reasons: 1. quite spammy, also disabled in Sentry 2. produces basically the same output as tracing server (output of which is collected and nicely rendered in the HTML) 3. makes the reading of logs from tests impossible; generates around ~120MB of logs which makes the UX of viewing it on TF unbearable and also download takes time Signed-off-by: Matej Focko <mfocko@packit.dev>
Reasoning: 1. Tests are run concurrently ~> no reasonable logs from pytest 2. We scrape tracing server for debugging purposes ~> additional artifact 3. Each test case is quite complex as it runs an LLM workflow, producing traces and also some metrics are collected ~> there's a lot of attributes that can be associated with each test Benefits: 1. Each test case is reported as separate subtest on tmt' side, therefore it is easy to bundle all the artifacts, collected metrics and test result together. 2. It is possible to tell at first sight which test cases failed, as they are reported by Testing Farm view separately and each test case is identified by the Jira ticket. 3. Collected metrics (displayed in terminal via pytest as a table) are presented as notes: - agent - tool calls - prompt tokens - completion tokens 4. Since test cases are run before the actual assertions happen, we can also propagate the duration of tests this way. pytest assertions do not capture the actual duration of the test case. Signed-off-by: Matej Focko <mfocko@packit.dev>
They are basically two separate steps, in case one of them fails, it is easier to trace and debug. Signed-off-by: Matej Focko <mfocko@packit.dev>
Signed-off-by: Matej Focko <mfocko@packit.dev>
I don’t really like the idea of running for »all« branches, as it would not be unusual to have some automation in repo. And even though the CI is triggered manually, there is still a read-only token for internal GitLab present… Therefore run on ‹main› and any branch that starts with the prefix of ‹test-pr/›. This also groups the refs for testing under ‹test-pr›, so the cleanup can be done easily from the shell. Signed-off-by: Matej Focko <mfocko@packit.dev>
|
@lbarcziova Summary of the changes since last review: |

TODO
Follow-ups:
I think I could adjust the provisioning for running the tmt tests locally to actually run locally 🤔 prepare clones the secrets and Jiras/repos from GitLab (needs the token exposed to env though…) and then everything is wrapped in the podman-compose, so locally it doesn't make sense to have one more layer of abstraction in form of VM (provisioned by tmt), OTOH it clones the secrets/Jiras/repos one more time :/