Last night, Mike (shalkie) and I had a nice discussion about the process we are now using to build / import packages. This is in preparation for now and the future. A lot of this discussion is thanks to Mathieu Bridon (bochecha).
I have inserted a few notes in the process below for clarification.
02:03 < herlo> k, so you should know that you first ‘skein request’ a package
02:03 < herlo> it can be done with either the –path or –name option, but one must be provided
02:04 < herlo> normally, one shouldn’t grant their own package. I should be around some tomorrow to grant packages in bulk for you as needed
02:04 < herlo> but
02:04 < herlo> if you do need to grant a package
02:04 < herlo> it should be something like
02:05 < herlo> skein grant -k <koji owner> -g <github owner> issue_number name
Package repos and koji tags are what get created with skein grant. However *only* an admin can grant a new package into our build environment. This is to make sure we are not putting packages into the process that are not part of the upstream and/or for a good review
process. In the future, I suspect quite a few people will be admins and this will be less problematic.
02:05 < herlo> once granted, the package can be imported with
02:05 < herlo> skein import /path/to/srpm
02:06 < herlo> usually though, I do take one extra manual step.
02:06 < herlo> I visit the repo page on github and add a service hook
02:06 < herlo> if you look at this page: https://github.com/gooselinux/libgnomecanvasmm26/admin/hooks
02:07 < herlo> you can see the ‘Post-Receive URLs (1)’
02:07 < herlo> if you click on it, you’ll see the url you should add for any new repo
02:07 < herlo> this post receive hook will automatically launch builds upon a commit
If you have admin access to a repository (and if a package has been ‘granted’ to you, then you do), add the following in the Post-Receive
URLs if it’s not already there:
02:08 < herlo> once you have that in place, run the import command described above
02:08 < herlo> at that point, everything should be pretty automatic.
02:08 < shalkie> k
02:08 < herlo> within 10 minutes, the build should automatically launch
02:08 < herlo> shalkie: seem pretty straightforward?
02:09 < shalkie> Yeah it does.
02:09 < herlo> k, so now it should also be clear that you may (and probably already do) have failed builds
02:09 < shalkie> The stack of email certainly suggests that.
02:09 < herlo> lol
02:10 < herlo> shalkie: a good portion of those can be run through again, though I have been working on fixing a few of mine
02:10 < herlo> shalkie: as you look through the failed builds, you may just need to run them again
02:11 < herlo> to do that, you can use
02:11 < herlo> skein build
02:11 < herlo> the way I usually do that is ‘skein build –nowait dist-gl6 <pkg_name>’
02:11 < herlo> only an admin can perform this task (you are an admin)
02:12 < herlo> you can watch the tasks at http://koji.gooselinux.org/koji as you always have, or go out for a
few hours and check the build statuses when you return
02:13 < herlo> BUT WAIT! There’s more!
02:13 < herlo> If for some reason, you determine something has to change in the spec file, like another dependency or something
02:13 < herlo> you’ll need to do two things
02:14 < herlo> first, clone the branch if not already there and then create a vanilla branch
02:16 < herlo> git checkout –track -b Â <local branch> <remote>/<tracked branch>
02:16 < herlo> eg git checkout –track -b vanilla origin/vanilla
02:16 < herlo> then push that vanilla branch
02:16 < herlo> git push origin vanilla
02:17 < herlo> this is so we can keep the original state of the package before we make any changes. I’ll be working onÂ automating this later
02:17 < herlo> when vanilla is pushed, we’ll go back to master and make our changes
02:17 < herlo> git checkout master
02:17 < herlo> <make changes>
02:17 < herlo> git add <files changed>
02:17 < herlo> git commit -m “message regarding changes”
02:18 < herlo> git push origin master
02:18 < herlo> again, when you push to master, a build will be launched within 10 minutes
02:18 < herlo> sit back, enjoy coffee and wait for the build to return
At the moment, the ‘master’ branch is currently what is getting built. Vanilla never gets built, but serves as a reference point to what the upstream did at certain points along the way. The vanilla branch also provides a way to merge in upstream changes with our changes. Git will
make this easy for us, because merge conflicts will be much easier to resolve across branches.
I hope this little conversation is a bit clearer on the process we’re trying to use. Look for further improvements coming to skein 2.1 (I already have quite the feature list) in the next few months.
PS – I likely won’t be online when this post is published as I’ll literally be enjoying some GoOSe, prepared by my lovely wife. She is an amazing cook / chef and is attempting this for the first time ever!