Wednesday, 18 November 2015

ANNOUNCEMENT: CI Train Status Reporting Changes

Hi everybody!

In a few moments I'll be rolling out a major change to the way CI
Train reports it's silo status.

Put simply, the train will become much more verbose/accurate about the
state that silos are in, and get much better about detecting problems
sooner rather than having surprises later.

In general, you can keep using the train the same way you always have.
There's no UI changes today. But there are a lot of bugs fixed!


* The bug where you can no longer un-dirty a silo by uncommitting new
commits on your MPs is resolved; if you push new commits the train
will detect that and indicate that a package needs to be rebuilt, and
if you uncommit those commits the train will detect that also and go
back to indicating the previous status.


* Many publish-time checks are now being run on a timer so you can
learn about problems well before you go to publish the silo. No more
surprises when you click publish!


* No more premature marking silos as dirty. Previously, if one silo
was published, it would mark conflicting packages dirty with a big
scary message saying "you must rebuild!", but if you rebuilt right
when that message popped up, it didn't actually fix the problem! This
is because you have to wait for the other silo to merge before a
rebuild actually resolves the conflict. I noticed this was causing a
lot of people to do pointless rebuilds prematurely, so I've eliminated
this. Now when you publish a conflicting silo, the other silos will
notice that there's a new upload at dest, but won't say "you must
rebuild" until there are actually new commits on the trunk branch for
you to incorporate.


* If your silo has multiple dirty packages and you only rebuild one of
them, the resulting status will explicitly tell you that the new build
succeeded, which is a big improvement over the old behavior of just
saying the one you weren't even building is still dirty, leaving you
to assume that the other was successful by a lack of error message.


So generally speaking you can look forward to train statuses that more
accurately and verbosely reflect the state the silo is in.


The only downside is that the new statuses are a little bit
information-dense, particularly with silos that have a lot of
packages. Typically speaking most of the packages in a silo will all
be in the same state (all built, or all in proposed), so instead of
repeating the same message multiple times, I've condensed redundant
messages. So a typical status may now look like this:


Successfully built [amd64 i386 armhf] (foo/xenial, foo/vivid,
bar/xenial, bar/vivid)


This means that packages foo and bar, in both xenial and vivid, and on
all the listed arches, has built successfully. If there's a build
failure on a single arch, it would look like this:


Failed to build [amd64] Successfully built [i386 armhf] (foo/xenial).
Successfully built [amd64 i386 armhf] (foo/vivid, bar/xenial,
bar/vivid)


Hopefully that isn't too confusing! I can iterate on this if people
have difficulty interpreting the results, and as usual if you find any
issues in general please let me know immediately!

Have a great day!

--
ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel