From 1f3128fc75e1e8629c4c9e1a2fa3cb739b21a8af Mon Sep 17 00:00:00 2001 From: Matej Focko Date: Fri, 4 Oct 2024 09:18:21 +0200 Subject: [PATCH] Add notes and Q&A from the review Signed-off-by: Matej Focko --- research/integrations/fedora-ci/index.md | 101 +++++++++++++++++++++-- 1 file changed, 94 insertions(+), 7 deletions(-) diff --git a/research/integrations/fedora-ci/index.md b/research/integrations/fedora-ci/index.md index faa0d2c..1b07ec6 100644 --- a/research/integrations/fedora-ci/index.md +++ b/research/integrations/fedora-ci/index.md @@ -33,12 +33,41 @@ the results of the SRPM build, i.e., just run `fedpkg srpm` and be done with it. This can be done within the sandbox as we do for non-scratch builds. However it might need some tweaking as Packit has specific worfklow. +:::note Questions from review + +> This is a very interesting point -- do we want to be consistent as much as +> possible with Packit's upstream implementation or be close to the real Fedora +> builds. +> +> I agree the suggested approach `fedpkg srpm` makes more sense from the user +> perspective since this results in the production-like result. + +With respect to downstream, I would be definitely voting for avoiding adjusting +the SRPM creation. Adjusting the SRPM creation in any way enables the chance of +inconsistencies, i.e., I have green CI, but once I merge it doesn't build. I +don't think many maintainers would like that :D + +> How do we want to handle sources? (Do we want to continue with the current +> trend of requiring sources in the lookaside cache?) + +I'm not really sure, but if we go deep into the possible improvements then it's +quite possible that most of this initiative will not be achievable :) + +::: + ### Koji scratch build We are already submitting scratch builds for merged PRs, if configured. This would just extend the functionality to the non-merged PRs (with need to provide the SRPM). +:::note Review + +And we have scratch build functionality for upstream PRs available as well if +this is anyhow relevant. + +::: + ### RPM linting, inspect and installability test There are premade tmt plans that we can run. @@ -47,6 +76,18 @@ There are premade tmt plans that we can run. Should these be run in parallel or sequentially and fail on first? +Follow-up question from review: + +> Are some of these somehow dependent? + +From the excerpt here (linting, installability, tests), it feels like linting +should not be a hard blocker. I've seen the installability tests fail (even if +tests passed) just because of the network flakes and such, so… + +In the sense of saving the resources, it definitely makes sense to make _full_ +_test suite_ dependent on the _installability_, but if it's flakey, it's just +annoying. + ::: #### Installability test @@ -157,6 +198,29 @@ Preferably it would be ideal to have separate deployment for the “dist-git onl service as handling all Fedora packages would definitely increase traffic and could cause issues with running as both Fedora CI and original Packit Service. +:::note Question from review + +> Would this mean `dist-git CI` and the current Packit? Or, Packit upstream and +> Packit Fedora automation (including Koji, Bodhi and maybe also propose/pull)? + +I've been thinking about a way to split this in some reasonable matter :D Based +on the way Packit operates, the most reasonable would be splitting the +upstream/downstream parts, i.e., + +- Packit Service (handles upstream **and** `propose-downstream` (as it is + triggered by upstream)) +- “Packit as Fedora CI” (handles downstream **and** `pull-from-upstream`) + +**However** I rant somewhere about the config in the dist-git and default config +:D and this complicates things a lot :/ Maybe we could treat PRs in a special +way for the _downstream PRs_ (Koji + TF). + +--- + +feels like whack-a-mole… + +::: + #### Default config Having a separate instance would also open up a door to a potential “default @@ -279,9 +343,25 @@ workflows, considerable overhead. ### GitLab -ogr has a support for GitLab already, reporting sucks a bit, but it's not -a blocking issue (due to the lack of upstream users, the priority of improving -the UX has been lowered). +ogr has a support for GitLab already, reporting sucks, but it's not a blocking +issue (due to the lack of upstream users, the priority of improving the UX has +been lowered). + +:::warning GitLab UX + +There are limitations on how Packit can improve the user experience on GitLab. + +GitLab is focused on providing the best user experience when using their own +GitLab CI, external services must either just report commit statuses (unlike on +GitHub that allows Check Suites and Check Runs), or integrate into the GitLab +codebase itself. + +This hinders the user experience significantly. + +> Switching from Pagure to GitLab sounds effectively like getting rid of the +> stability issues while maintaining the poor UX. + +::: #### Upstream vs downstream @@ -320,14 +400,17 @@ helpful in this case a lot). - [ ] Consider this in the design. - [ ] Should not cause any annoyance for _proven packagers_ +:::note Review + +There's an [RFE](https://github.com/packit/packit-service/issues/1723) for +a workflow that involves auto-landing PRs in the Fedora dist-git. + +::: + ## Follow-up cards - [ ] Allow triggering of the Testing Farm with Koji build (instead of the Copr build) -- [ ] Allow triggering of the Testing Farm **STI** tests with Koji build (or in - general) -- [ ] After PoC and final decision, deploy a separate instance to handle only - Fedora CI queue - [ ] Try to unify _installability pipeline_ with the tmt plan for install test that we already have - [ ] Packit needs to be able to deduce the build target based on the branch @@ -336,3 +419,7 @@ helpful in this case a lot). from the config) - [ ] Allow Packit to have customizable default config (more details above) - [ ] Allow Packit to run without any config (utilizing the previous point) +- [ ] After PoC and final decision, deploy a separate instance to handle only + Fedora CI queue +- [ ] Allow triggering of the Testing Farm **STI** tests with Koji build (or in + general)