Koji import versus add-pkg

[Otto Han]

On Tue, Dec 16, 2014 at 8:23 AM, Mike McLean <mikem at redhat.com> wrote:
> 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?
>
Yes, we use perforce.
I understand importing frequently the SRPM is fine because there is no
way to alter the sources through Koji. Doesn't mean this will somehow
overload the Koji system in time? Is there a way to "purge" the source
RPMs to prevent this situation?
I mean once a build is done there is no reason to keep the sources in
Koji as they are, already in CMS.  On the other hand I understand
there is no way to remove / delete a package once in Koji. How can we
deal with this case?

> --
> buildsys mailing list
> buildsys at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/buildsys