[V3dot10] Prototyping an autobuild system

[Ralph Johnson]

On 1/16/07, Keith Hodges <keith_hodges at yahoo.co.uk> wrote:
> a. A script runs periodically to check an rss feed to see if any pages
> have changed. It only looks at the first 150 lines or so to obtain the
> most recent changes rather than wasting time parsing the whole lot.
> (alternatives, check a mailbox file, or run a smail script on receipt of
> email - I think that the rss solution is the most generic)
>
> b. the script picks and logs the first page whose change date is more
> modern than the last page the script processed. It records the change
> date in a file.

I have been trying to figure out why you would want to do this.  My
first reaction was that this was completely crazy.  I do not want a
build process to randomly execute ANYTHING, but want it to be
repeatable.  But I think I figured it out.

First, you are not talking about an autobuild server, you are talking
about a test server.  The purpose of this is to test a set of changes
against all the different images that are supposed to be built from
those changes.  "stable", "dev" and "full" are not branches, they are
images built from different configurations of packages.  This is very
important!

Second, you are trying to define the UI of the test server.  You want
people to be able to  define a new configuration or a new set of
changes and then to have the test server produce a set of results for
those tests.  Do you agree?

There will be plenty of pages on the wiki that are NOT direct input to
the server.  I think it would be a mistake to have the server
automatically execute every page.  For one thing, someone might submit
a page many times before it is ready to be executed.  I think that
pages need to be tagged "ready to execute", and the test server should
only execute ones that are ready.

Also, if this is really a UI for the test server then it ought to
display results, not just input.  Once the test server has run tests,
the wiki page that defines the test should also give the result, at
least "red" or "green".

Here is an easy way to both control job execution and to control what
results are displayed.  There should be a Squeak command to define the
name of a job, such as "Installer jobNamed: 'devWithREJ2-5-07changes'"
and then at the end of the page I put a link to
"http://testserver.squeak.org/devWithREJ2-5-07changes.gif" which
includes a little green picture that ways "4230 tests passed" or a
little red one that says "4230 tests run, 5 failed".  If a job hasn't
been run yet then the picture won't be there, and you have to refresh
the page to see it.  Dynamic refresh would be better, of coruse.
Perhaps a little JavaScript.

So, I do not think that Keith is talking about branches in the cvs
sense.  Those of us who hate branches can calm down.  He is talking
about testing many different configurations of packages.

-Ralph