Hi Adam, Thank you so much for replying, it helped a lot!
-- Best regards, Beatriz Santa Catarina State University - UDESC Em dom., 20 de jun. de 2021 às 03:45, Adam Williamson < adamw...@fedoraproject.org> escreveu: > 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@lists.fedoraproject.org > To unsubscribe send an email to test-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure >
_______________________________________________ test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
