Updating the build process (somewhat)
Clint Savage
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).
Anyway, 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:
http://roman.gooselinux.org:8080/add
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.
Cheers,
Clint