<tt><font size=2>amessina@messinet.com wrote on 11/05/2013 11:08:49:<br>
<br>
> On Tuesday, November 05, 2013 10:46:55 AM John.Florian@dart.biz wrote:<br>
> > amessina@messinet.com wrote on 11/04/2013 18:56:08:<br>
> > > On Monday, November 04, 2013 05:28:28 PM John.Florian@dart.biz
wrote:<br>
> > > > From what I gather, mash is the tool of choice for
composing usable<br>
> > > > repositories out of koji's build efforts. What
advice do y'all have for<br>
> > > > integrating the two? Presently, I've got mash
running via cron every<br>
> > > > 15m<br>
> > > > but that hardly seems optimal as it's a lot of busy
work if I'm not<br>
> > > > building packages for several days and conversely adds
more latency into<br>
> > > > my<br>
> > > > build + deploy + test timeline if a build finishes
right after mash<br>
> > > > does.<br>
> > > > Seems like a hook or callback is in order, but
I've not seen any write<br>
> > > > ups<br>
> > > > on this subject. Also, I had a rpm built by koji
which then made it<br>
> > > > over<br>
> > > > to my repo via mash, but then I got busy for a few
days on other tasks.<br>
> > > > When I came back it appears that my rpm has disappeared
from the repo.<br>
> > > > I'm guessing kojira cleaned it up, but I was
under the impression that<br>
> > > > such cleanup wouldn't propagate to the repo.<br>
> > > <br>
> > > I use a very custom koji-maint [1] script, but you could
take a look at<br>
> > > the mashCreateRepos function for some ideas. I
run it from a systemd<br>
> > > timer unit once a day. You could have systemd run
it more often if you<br>
> > > wanted,since the design goal was to only have mash create
new<br>
> > > repositories *if* the file date from the previously created
repo is older<br>
> > > that the last package tagged in the specific Koji build
target.<br>
> > > <br>
> > > -A<br>
> > > <br>
> > > 1. </font></tt><a href="https://messinet.com/trac/browser/koji-maint/koji-maint"><tt><font size=2>https://messinet.com/trac/browser/koji-maint/koji-maint</font></tt></a><tt><font size=2><br>
> > > <br>
> > > --<br>
> > > Anthony - </font></tt><a href=http://messinet.com/><tt><font size=2>http://messinet.com</font></tt></a><tt><font size=2>
- </font></tt><a href=http://messinet.com/~amessina/gallery><tt><font size=2>http://messinet.com/~amessina/gallery</font></tt></a><tt><font size=2><br>
> > > 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E<br>
> > <br>
> > Thanks for that link. Looks to have all sorts of handy
features. Package<br>
> > signing is another item on my checklist and I see you've got
code in there<br>
> > for that too. I'll have to hack on this (or so it appears)
to get it<br>
> > working with certificate-based authentication. Would you
be interested in<br>
> > any such patches?<br>
> <br>
> Sure, John. I would appreciate patches. Thanks. Though
I'd like <br>
> to see most <br>
> of this type of work end up upstream in koji-gc or kojira ;)<br>
> <br>
> I wish I knew Python...</font></tt>
<br>
<br><font size=2 face="sans-serif">I know Python very well, I wish I knew
my way around koji. :-)</font>
<br>
<br><font size=2 face="sans-serif">It's been quite a battle trying to follow
the various wikis, blogs and etc. on getting a setup going and there seems
to be even less written on how to actually use it in practice. Part
of my difficulty probably stems from having built my own tool chain and
using that for so long; I'm biased on approach. I'm trying to convert
now to mainstream practices because I want a more automated setup where
git commits to my numerous projects yields rpms which yield repos which
yield custom Fedora Live images which yield VM builds and automated testing
all along the way in a huge continuous integration loop.</font>
<br><font size=2 face="sans-serif"><br>
--<br>
John Florian</font>
<br>