Hey guys, So I've finally got around to learning lauchpadlib and pbuilder (as well as got annoyed enough by recent fallout in daily PPA and merge requests taking forever in review), so I've spent the past few days putting together automated scripts for downloading, building and installing arbitrary code and merge requests. They should massively simplify testing experimental code - and the testing will be actually representative. They work for me now, but I could use additional testing and input on the UX design of this thing before we roll them out to adventurous users.
The problem with testing proposed code recently is that it was performed by developers. This is wrong on several levels. First, such testing is not representative because developer machines are typically tainted with make install's and miscellaneous fallout from older versions - this is why two merge requests that caused the programs to crash on startup have passed such testing. Second, developers have better ways to spend their time than testing code of others. I've tried to automate the process as much as possible, and I think I achieved just that. The actual testing is still performed manually, but everything else is automated. Here's an overview of my scripts: elementary-test-merge: receives only one parameter - merge request URL - and then automatically merges the branches (including the prerequisite branch, if specified), builds a source package from the code, sets up a clean build environment in complete sync with latest environment specified in lp:elementaryos, downloads the build dependencies, builds the code into Debian packages and installs them, cleanly replacing the PPA versions. I don't think there's anything else I could automate here :D The epic upside of this one is that it enables really actually representative testing (unless the machine is tainted with make install's - never do them!), while running things from source directory is not representative and everything else is either too tedious or taints the system. The catch is the target branch for the merge should have a recipe that builds to elementary Daily PPA (or any other PPA you specify - but it should have a working recipe). And merge requests that introduce additional build dependencies cannot be tested with it, but fortunately they're rare. I might use auto-apt to fix this later on. elementary-install-from-bazaar: downloads, builds and installs code from a bazaar branch, optionally merging additional branches into it. This may be of interest to users and developers alike. The simplest use case is building and installing latest code from trunk without waiting on daily PPA. That's also what the merge request testing script uses as a backend. And I test my changes that affect data files and GSettings schemas by running "elementary-install-from-bazaar lp:projectname local/branch/with/my/changes". The script distinguishes between local and custom builds and marks them accordingly; both receive versions inferior to those of actual PPA builds, so you can revert to PPA packages simply by updating your system. The catch is the same - it needs a working recipe for primary branch. Optionally can build packages without installing them. elementary-auto-pbuild: serves as a backend for the above scripts; will be useful on its own only to people messing with Debian packaging and who know what pbuilder is. This is a zero-setup pbuilder with always-up-to-date Luna environment; just feed your .dsc to it and it will spit out .deb packages, no messing with configs required. As I said, even though the scripts work for me, could use some more real-life testing. They could also use better documentation and better error reporting, but I'll do that as interfaces stabilize and as we figure out what causes the errors. Also, since some lower-level settings are passed in environment variables, these scripts could really use a manpage, but I have no idea how to write one. Any assistance on that is appreciated. Looking forward to your reply -- Sergey "Shnatsel" Davidoff OS architect @ elementary
-- Mailing list: https://launchpad.net/~elementary-dev-community Post to : elementary-dev-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
