On 12/15/2014 07:11 PM, Otto Han wrote: > On Fri, Dec 12, 2014 at 1:20 PM, Mike McLean <[email protected]> wrote: >> On 12/04/2014 01:57 PM, Otto Han wrote: >>> This last sentence is very important for me. We are using Koji as sort >>> of Package-MgtSystem (package repository). We are building rpm from >>> srpm in a Jenkins environment. When Jenkins is done and no error was >>> noted we import all built packages in Koji and tag them. >>> The source code is maintained in a perforce CMS. When developers reach >>> a stable phase they generate SRPM from the source code and then run a >>> Jenkins job to generate the RPM. The result is a temporary local >>> repository containing all SRPM and RPM of the build. >> >> I know that folks have wired Jenkins to trigger builds inside of a Koji >> instance. I wonder if that would work for you. >> >>> These packages >>> are then imported in Koji and appropriately tagged: >>> - koji import *.rpm >>> - for all untagged: koji call tagBuildBypass tag package >>> For us importing is a very common practice. >> >> If I were doing this sort of mass import all the time. I would first >> generate a list of the srpms these rpms were generated from (which >> determines the build they will be associated with upon import). E.g. >> >> # rpm --nosignature --nodigest -qp --qf '%{sourcepackage} %{sourcerpm} >> %{n}-%{v}-%{r}\n' *.rpm |awk '{if ($1=="1") { print $3 } else {print >> gensub(".src.rpm$", "", "", $2)} }' >> >> (The complication above is to deal with the srpm case (just use that >> nvr) vs the non-srpm case (use the sourcerpm value). >> >> Anyway, I would save that list and then tag those nvrs after import. >> >> Using list-untagged is not very reliable here, as there are lots of >> reasons that a build might become untagged. You might end up tagging >> something that you don't mean to. >> >> >>> Having said all this what is your advice and what do you think of this >>> way using Koji ? >> >> Well you're not really using most of koji, and you're losing many of the >> advantages. With this approach you have very little build metadata in >> koji. Garbage collection will be much less intelligent. >> >>> Rarely we have a brand new package which does not exist yet in Koji. >>> Import *.rpm will insert it in Koji but how can I detect I must run >>> add-pkg for it before tagging? >> >> You could use the koji list-pkgs command to check for it. Or you could >> just run koji add-pkg every time. If the package is already present, it >> is a no-op (though it will print a warning). >> -- > > Thanks for the help. > > If I can abuse of your time... There is a thing I cannot grasp. If I > keep the sources in Koji as SRPM then how do I deal with the project > advancement. We are modifying on a regular base the sources (under > perforce) then we build the SRPM and RPM and import them in Koji. Is > there a Code Management feature in Koji ?
Koji is not a source control solution. We assume folks have their own solution for that. Personally, I like git. Didn't you say you were using perforce? -- buildsys mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/buildsys
