Added 'autokrank' to kteam-tools

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Added 'autokrank' to kteam-tools

Khalid Elmously
Hi

I mentioned that I've been using a quick and hacky script to try to automate the kernel cranking, the idea being hopefully to save time and reduce errors. It's been working OK so far. On suggestion from Brad, I've added it to kteam-tools. Following is a brief how-to on how I've been using it.

(Before using it the first time, you will need to copy autokrankrc to ~/.autokrankrc and modify it to specify the locations of the 3 git repos (that will be used to crank linux, signed and meta packages) and the names of the chroots. The git repos can start out empty - they will be reset from origin. The chroots need to be prepared for cranking beforehand)


I normally start with something like:

# Clear any old branches and tags from the autokrank repos
./autokrank --purge

# Initial attempt at cranking all the masters and derivatives (backports can't be cranked at this point)
for i in
   bionic--master.krank
   bionic-aws.krank
   bionic-gcp.krank
   bionic-kvm.krank
   bionic-raspi2.krank
   trusty--master.krank
   xenial--master.krank
   xenial-aws.krank
   xenial-kvm.krank
   xenial-raspi2.krank
   xenial-snapdragon.krank
   trusty-aws.krank; do

        ./autokrank --tasks 101010 --sru-cycle 2018.08.20-1 $i
done;


(Note 1: '--tasks 101010' means crank linux, signed and meta - but do not construct the source packages for linux, signed or meta (this is just for expediency for now - there will be another 'real' run later and we'll build the pkgs then))
(Note 2: if there's no current SRU cycle or if I don't want to modify the tracking bugs, I use '--no-link-to-tracker' instead of '--sru-cycle <cycle-name>')
(Note 3: The order of the above kernels matters. Derivative must be autokranked such that the 'last autokranked master' is the master that they're based on - this is why trusty-aws comes after xenial--master not after trusty--master)


By the time the loop is done (which can take several hours), there should be a new branch for each of the above .krank files in each of the 3 autokrank repos (except for the ones that don't have -signed - those will only have branches in the linux and meta repos). At this point I go through the branches in the linux tree making sure they are sane. It is possible that there may be config changes generated by 'fdr updateconfigs' that were committed as part of the closing commit. We don't usually allow config changes as part of the closing commit, so these config changes need to be manually pre-committed and pushed to the origin tree.

After verifying that the trees look sane and that any config changes have been pre-committed to the origin tree (if necessary), I purge the autokrank repos and do another 'real' run:

./autokrank --purge

for i in
   bionic--master.krank
   bionic-aws.krank
   bionic-gcp.krank
   bionic-kvm.krank
   bionic-raspi2.krank
   precise--master.krank
   trusty--master.krank
   xenial--master.krank
   xenial-aws.krank
   xenial-kvm.krank
   xenial-raspi2.krank
   xenial-snapdragon.krank
   trusty-aws.krank; do

        ./autokrank --sru-cycle 2018.08.20-1 $i
done;


(Note: Omitting the --tasks option means "do everything", i.e. same as '--tasks 111111')

By the end of this second run, I expect all the trees to be correctly cranked and tagged and the packages to be properly generated. I double check the trees again, run 'verify-release-ready' on all of them, verify all the .changes files, and for full marks, I debdiff the source packages against the previous versions.

If all is well, then the tags should be ready to be pushed and the source packages should be ready to be uploaded to the PPA.




Once the masters and derivatives are pushed, I am ready to autokrank the backports. Order doesn't matter here:

for i in
   trusty-ltsxenial.krank
   xenial-gcp.krank
   xenial-hwe.krank
   precise-ltstrusty.krank; do

        ./autokrank --sru-cycle 2018.08.20-1 $i
done;

Like before, there should be a branch in each of the repos for each of the .krank files. I check the branches, run verify-release-ready, review the packages, etc. and if all is well they should be ready to be pushed.



That's basically it as far as I normally use it. Here's some additional info:

 - autokrank does everything in its own 3 repos - so using it should always be 'safe'. Just make sure to use --no-link-to-tracker if you don't want to modify the launchpad bugs.
 - You can monitor the high-level overview of what's happening by doing 'tail -f /tmp/autokrank.log'
 - If the master tree has already been cranked (say by someone else) and you want to crank only the derivatives, you can specify '--master-tag <tag_name>' to specify the master tag upon which the derivative should be rebased. This option is only relevant for derivatives and is ignored by masters and backports. When this option is NOT specified, derivatives get rebased on 'the most recently autokranked master'.
 - Generally autokrank produces the right result - the only situation where it doesn't seems to be when there's a rebase conflict in a derivative. There's really no good way to handle this right now. One option is to manually crank the problematic linux tree and push it to origin, then re-run autokrank on that kernel with '--tasks 011111' so as to skip cranking the linux tree and just construct the src package for it then crank and build -meta and -signed.


Thanks
Khaled

--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team