Heikki Toivonen wrote:
bear wrote:
There is one major problem with this approach, due to the way our build
is set up where chandler/ can be out of sync with external/ and
internal/. We could either decide to live with the hopefully relatively
short breakages on these two Tboxes when external/ and internal/ change,
or do something about fixing this.
I don't know why I shouldn't be able to spend an afternoon, wrap my head
around the problem and come up with a solution that, at a minimum allows
for the Chandler side testing to continue even if the external side is
currrently failing.
One simple solution would be to break the tbox up into two distinct
steps, each with their own report sub-steps.
We haven't been able to provide a satisfactory answer to this problem
since we split into external/, internal/ and chandler/, so I am not so
sure it would be a simple fix.
The reason it breaks now is because the external process does an install
step that puts the generated tarball into the Chandler's download
directory. What I am imagining is that the external build place the
tarballs into a directory named something like external_downloads and
runs all of the Chandler tests pointing CHANDLERARCHIVES at that
directory. This will test the new tarball.
When the next step (the new one that also would run Functional Tests)
runs, it would remove the CHANDLERARCHIVES def and that would pull then
from the stable downloads directory.
This allows for both sides to be tested.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
