...
BeamTestReport should be relinked against the new version of BeamTestRelease.
Neither BeamTestELog nor ConfigTables need to be relinked, as they are implemented in Python.
...
Pipeline Tasks and Associated Scripts
...
Pipeline tasks are structured as a linear chain of steps. Each step must succeed before going on to the next one. Each step must be attempted, until one fails or the last one succeeds. That is to say, there is no flow control, and no parallelism. In order to deal with this, and to reduce the chance that a step would not be reached due to the failure of a previous step on which it did not logically depend, the work we do in the pipeline is split into 7 tasks, all but one of which (updateELogDB) are launched by other tasks. This launching is done without GINO's (the pipeline infrastructure) knowledge.
The sequence of steps within a task is set by an XML file that is uploaded via the GINO front end to create the task. This file also sets up input & output files, what code to run, which batch quesues to run it on, etc. The XML files are generated by perl scripts in the task directories under $beatestPlRoot.
There is no file, script, datastructure, or anything outside the maintainer's head that codifies the global structure of it all.
Tasks launch other tasks using the $beamtestPlRoot/lib/TaskLaunch.pl script. My convention has been that I launch each task in a separate TP. The TP and the script and wrapper that it uses have names beginning with "Launch".
The names of files registered with GINO is constrained to follow a certain format. When one task produces a file that is used as input to another task, the name given by the first task is not the name expected by the second one. Thus, part of the process of one task launching another is to create symbolic links with the name expected by the downstream task.
...