[Testtools] Accumulating a configuration (nightlyBuild main loop)

[J P Fasano]

testtools-bounces at list.coin-or.org wrote on 01/16/2009 07:51:48 AM:

> Gents,
> 
>    JP and I have been exchanging emails about BuildDirSuffix, and he's 
been
> persistent enough to convince me that there's a possibility of 
accidental
> persistence from one build to the next.  I'm testing out a fix (pop the 
value
> from configuration if it's not specified for a given build).  But it
> seems to me
> the problem really lies in the way that the main loop of 
> nightlyBuild assembles
> a configuration. We're in nightlyBuild.py.
> 
>    Where it says `Define loop invariant configuration values', we
> initialise a map (configuration) and a set of sets (configurations). 
Prior to
> entering the loop on projects, some persistent keys (rootDir,
> buildMethod) are set in configuration, to be used by all projects.
> 
>    Now we enter the project loop (`Loop once for each project ...').  We
> set two more keys, project and `clear previous build', to be used 
> for all builds
> of a project. (Arguably, `clear previous build' should be handled as a 
> persistent key, since it's initialised from a global variable.)
> 
>    Now we enter the build loop, processing the builds specified for the
> project. We fill in a whole bunch more keys in configuration. 
Eventually, we
> check to see if configuration is already in configurations. If not, 
> we process 
> it (NBbuildConfig.run) and record it in configurations.
> 
>    Now, it seems to me that at this point the logical thing to do is 
clear
> configuration back to an empty map and start over to fill in 
configuration for
> the next build, but that doesn't happen.  The consequence is that once a
> key:value pair is added to configuration, it persists until explicitly 
removed
> or changed.  This is not safe.  I'd like to propose something a bit 
different,
> but fairly close to what now exists.

Sounds like a prudent thing to do.


> 
>    There are three classes of keys in a configuration:  top-level (for 
all
> projects), project-level (for all builds of a project), and build-
> level (for an
> individual build).  Right now, rootDir and buildMethod are handled 
> as top-level,
> project and `clear previous build' are handled as project-level, and all 
the
> rest are (or should be) handled as build-level.
> 
>    Why not make this explicit, by creating two new variables,
> top_configuration and project_configuration.  These get loaded at the 
places
> where top-level and project-level keys are processed now.
> 
>    Then, in the inner loop (`for bc in buildConfigs'), the first action
> is to clear configuration and load it with the values from 
> top_configuration and 
> project_configuration. This should prevent accidental carry-over.

You have obviously studied and thought about the code more than myself.
>From my perspective it sort of grew and had more things patched into it 
(as I learned and experimented more with python).

The changes you suggest are fine with me.

If you would feel more comfortable not making bigger changes trunk, feel 
free to make a copy in branches.
I could then check out the branches and run a test on the 4 platforms 
where I currently nightlyBuild.
But I think it is OK to make changes in trunk.
After all, there aren't many people using nightlyBuild.

> 
>    Documentation and code comments should be updated to reflect the 
three 
> classes of parameters. As an added benefit, the user could override 
top-level 
> and project-level keys in a build configuration, should s/he so desire.

More documentation is of course good.
> 
>    You guys will regret dragging me into this ...   :-)

No & No.
I most certainly don't regret it.
I don't really think you feel dragged into this either (at least I hope 
not).


> 
>                      Lou
> 
> _______________________________________________
> Testtools mailing list
> Testtools at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/testtools
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.coin-or.org/pipermail/testtools/attachments/20090116/62ffe1ad/attachment-0001.html