Koji import versus add-pkg

Mike McLean mikem at redhat.com
Tue Dec 16 16:23:19 UTC 2014


On 12/15/2014 07:11 PM, Otto Han wrote:
> On Fri, Dec 12, 2014 at 1:20 PM, Mike McLean <mikem at redhat.com> 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?



More information about the buildsys mailing list