elementary-dev-community team mailing list archive

["Sergey \"Shnatsel\" Davidoff" <sergey@xxxxxxxxxxxxxxxx>]

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