ubuntu-phone team mailing list archive

[Robert Park <robert.park@xxxxxxxxxxxxx>]

Hi everybody!

I've been working on some experimental changes in Bileto, and I'd like
to get some early feedback before forcing these changes on everybody
in the next week or so.

In the staging instance, I have a quite large experimental refactoring
of the train code, with a number of advantages:

* builds are now parallelized instead of serialized, which means
source packages can be built & uploaded much faster than they
currently are. By rough estimation, a silo with a few packages in it
might have taken 20 minutes to build source packages before, now it
takes just a couple minutes.

* bzr knowledge is being encapsulated in a way that will make it easy
to implement git support later (yes, sadly, git support is still not
here, but this is a step in that direction)

* jenkins is being replaced, so no more stupid issues with clicking
'build' and then nothing happens because the button just redirected
you through SSO and back without actually triggering the build, among
many more jenkins-isms being nuked from orbit. for now only the build
job is replaced, the others remain.

So if you are a user of requests.ci-train.ubuntu.com, please help me
find regressions by doing these quick steps for me:

1. Visit https://requests.ci-train.staging.ubuntu.com/ and sign in with SSO

2. Create a new request and put some MPs in it

3. Click 'Assign' and run that jenkins job as per usual

4. Click 'Build' and marvel at the new Bileto job page, then run that too

5. Observe the console output and make sure nothing explodes, and then
at the end observe the low, low build times.

6. Inspect https://code.launchpad.net/~untrusted-ci-dev-bot to see if
the resulting source package has the contents you expected.

7. Check back later to see if your binary packages built successfully
or not. Note that packages built this way are not actually releasable
to ubuntu, so your help here is purely a selfless effort to find bugs
in bileto. You're so kind! Thank you!



Here's an example of a simple one I grabbed from production:

https://requests.ci-train.staging.ubuntu.com/log/1170/build/1

92 seconds to build, upload, and diff yakkety, xenial, and vivid
copies of ubuntu-system-settings! Blazing fast!


KNOWN ISSUES:

* the staging version of the stable-phone-overlay ppa is woefully
incomplete and so most vivid builds are expected to fail and generated
diffs will be much larger than you expect.

* the feature where it automatically detects new commits is sadly
missing, this is because the code that does that detection hasn't been
ported over yet, but once I get this rolling, restoring that feature
will be my top priority.

* builds can't be cancelled, but I suspect that they happen so quickly
now that cancelling them isn't really terribly feasible. let me know
if I'm wrong about this.



Also, friendly reminder, please subscribe to bileto-announce list if
you are a regular user of requests.ci-train.ubuntu.com, as I will
sooner or later phase out posting updates to ubuntu-phone list.
Thanks!

https://launchpad.net/~bileto-announce

-- 
robru