On Wed, Dec 3, 2014 at 5:21 PM, Mike Bonnet <[email protected]> wrote: > On 12/3/14 4:29 PM, Otto Han wrote: >> >> On Wed, Dec 3, 2014 at 3:18 PM, Mike Bonnet <[email protected]> wrote: >>> >>> On 12/3/14 2:34 PM, Otto Han wrote: >>>> >>>> >>>> Using koji what is the meaning of add-pkg ? I understand I use import >>>> to add a package and tag-pkg or "call tagBuildBypass" to put a tag on >>>> this package. Must I call add-pkg in between? >>> >>> >>> >>> koji add-pkg adds a package to the whitelist for a tag. Before you can >>> tag >>> a build into a tag, you need to add the package to the tag whitelist by >>> calling: >>> >>> koji add-pkg <tag-name> <package-name> --owner <owner-name> >>> >>> where <tag-name> is the name of the tag you're trying to tag the build >>> into, >>> or one of the tags that is inherited by that tag. To see the current >>> package whitelist for a tag, run: >>> >>> koji list-pkgs --tag <tag-name> >>> >>> This will show the full whitelist, including inherited entries. >>> >> >> OK. But then what "koji list-untagged" shows? Packages not belonging >> to any white list at all or they may be in a white list but not yet >> tagged ? If this is true then how can I see packages imported but not >> yet included in a white-list. > > > koji list-untagged shows *builds* that are not associated with any tag. > This could be because a build was imported and not tagged, or (more > commonly) because a build has been untagged, possibly by the > garbage-collection process (koji-gc). > > Example: you want to import findutils-4.5.14-1.fc22 and tag it into the > my-imports tag > > $ koji import findutils-4.5.14-1.fc22.src.rpm \ > findutils-4.5.14-1.fc22.x86_64.rpm \ > findutils-debuginfo-4.5.14-1.fc22.x86_64.rpm > > (this creates a findutils-4.5.14-1.fc22 entry in the database, assuming > it doesn't already exist) > > $ koji add-pkg my-imports findutils --owner otto > > (the argument to --owner would be whatever your koji username is) > > $ koji tag-build my-imports findutils-4.5.14-1.fc22 > > Note that importing rpms isn't common practice. If you're just trying to > get to the point where you can build rpms in Koji, you should be setting up > external repos as outlined here: > > https://fedoraproject.org/wiki/Koji/ExternalRepoServerBootstrap > > > -- > buildsys mailing list > [email protected] > https://admin.fedoraproject.org/mailman/listinfo/buildsys
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. 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. Having said all this what is your advice and what do you think of this way using Koji ? 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? -- buildsys mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/buildsys
