On Sat, 2021-06-19 at 13:53 -0300, Beatriz Michelson Reichert wrote: > Hi Adam, thank you for replying, it helped a lot! > > I have some more questions about the composes and Koji, and would like to > know if you could help me with the questions about this subject too: > > 1. What repository does Koji forward the build of a package and the RPMs > to? > 2. The nightly compose process receives some package builds as input. > What repository are these builds in? Is it the same repository as the > previous question? > 3. The candidate compose process receives the candidate packages (stable > packages) as input. What repository are these candidate packages in? Hi Beatriz! So these questions are sort of...backwards, in a sense. The compose processes are what *produce* the repositories. Koji doesn't exactly build packages and then put them in a repository. Well, technically there is a repo metadata 'view' of each Koji tag. You can find those at kojipkgs.fedoraproject.org/repos/ - each tag has a directory there, and you can find repodata under each directory which gives you a repo 'view' of the latest builds for that tag. But those are not things that are really intended to be consumed by Fedora users or testers in most typical workflows. I think the best way to think of it in terms of how most processes work is that Koji builds packages and then they just sort of...sit in Koji to be used as inputs to other things. A "compose" is the mechanism by which we take builds from Koji and produce the things that Fedora users 'consume', including images and the formal public-facing repositories. So, just running a build in Koji does not necessarily result in it appearing in any conventionally-public-facing repository. For Rawhide there are some convenience mechanisms hooked up so when a packager does a build the "usual" way, it automatically gets tagged for Rawhide and included in the next compose, but even that can be avoided if desired. For a build to appear in a public repo, some kind of compose step has to happen in between. To answer q2 directly - the nightly compose process for Rawhide and Branched uses the packages tagged with the stable tag for the release in question. So currently Rawhide composes use all packages tagged 'f35'. When F35 branches, Branched composes will use all packages tagged 'f35' and Rawhide composes will use all packages tagged 'f36'. The composes that are run regularly to update the stable release update repositories use the '-updates' tags - so when we run a compose to update the F34 stable updates repo, for instance, it uses all packages tagged 'f34-updates'. (There are also composes run to update the updates-testing repositories for stable releases and Branched; these use the 'fXX-updates-testing' tags, not surprisingly). When a stable release update is "pushed stable" via Bodhi, what actually *happens* that makes it ultimately show up in the public stable updates repo is that it has the 'fXX-updates' tag applied to it in Koji, so the next stable update compose run pulls it in. (For Branched and Rawhide, when an update is 'pushed stable' via Bodhi, it has the fXX' tag applied, so the next nightly compose pulls it in). Note that your q2 and q3 are phrased slightly wrong, btw. It's nightly composes that use "[all] stable packages" as input. Those composes are automated and use *only* the packages tagged 'f35' or 'f36' or whatever. Candidate composes can potentially pull in additional packages. The difference between a candidate compose and a nightly compose is some slightly different naming, configuration and metadata produced by running the compose tool differently, *plus* the potential to manually include packages that have not yet been 'pushed stable', which is done by releng by hand. Here's an example from the last release: https://pagure.io/releng/issue/10093#comment-729024 that was the candidate compose request I filed that resulted in F34 Final RC2 being built, which is ultimately what was released as F34 Final. As you can see, I listed 9 updates to be included in the compose which were not 'stable' at the time. The automated nightly compose run on the same day would not have included those updates. In order to include them, releng would have tagged them into a side repository that is included in the candidate compose configuration before running the compose. I actually forget what that repo is called :P Again, mboddu could tell you. All of the above is my best recollection/understanding, btw - if Mohan or Kevin Fenzi tell you something different, they're probably right. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/test@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
