[Buildbot-devel] copying information between steps or schedulers

[Stefan Seefeld]

A.T.Hofkamp wrote:

> I thought about passing information from one step to another yesterday 
> evening, and it seems there is another (bigger?) obstacle here, one step 
> further down the road.
> 
> Suppose we have this dictionary with information which is passed on from 
> step to step. How is information from this dictionary then forwarded to 
> the shell script, python script, C binary, etc used to perform the 
> actual step?
> (ie how to go from { 'svnrevision' : '2938' } in a Step object to having 
> '2938' in '$revision' in my shell script/python program/binary/etc?)

Right now users specify steps in the master.cfg file by providing string-based
commands. Assuming steps to have some toplevel 'run' method (just to illustrate
my point), I could imagine users to be able to derive their own Step classes
inside master.cfg, where they can provide their own 'run' version that accesses
the shared context. In the end they would of course delegate down to existing
methods, but instead of setting up the 'command' during initialization they
could do that at runtime, taking the specific state of the context dictionary
into account. I'm not sure whether that is viable, or whether there are better
ways to communicate state between steps. May be some buildbot developers could
comment on this ?

> Also, to update the dictionary, we need to go back, ie if some program 
> produced 'my-file-r2938.tar.gz' and we want to add that to the 
> dictionary as 'resultfilename', how does a Step object obtain the 
> information that it should do that from the script?

See above. User-steps should then be able to inject new variables into that
context dictionary, too, in the same way they can read from it, as defined
in master.cfg.

> At the input side of the script, I can see a solution with pattern 
> substitutions, ie I would write a step as
> 
>   s(step.ShellCommand, 
> command=['tar','xzf','myfile-r%(svnrevision)s.tar.gz'])
> 
> maybe we should optionally be able to specify which substitutions should 
> take place here.

Right. The problem with that is (IIUC) that this substitution would take place
at initialization-time, not run-time. Thus my suggestion involving user-defined
Step (proxy) classes.

> At the output side, things seem more difficult; how to state which 
> changes should be made in the dictionary as a result of executing the 
> command, and what values to use for the changes?

Same here: if this can be done from inside master.cfg, it becomes the user's
responsibility to state that.


Regards,
		Stefan