Develop CI checks for jO that require new base fragments
An example can be found in 421xxx/421002
.
Perhaps for the moment we don't need anything more than the run_athena
job implemented in the run_athena
branch, but this will not catch the problematic case described below.
Someone has 421002 locally where they override the common file with their local one and then they forget to push it to the repo.
The athena job in this case still runs (see attachment below) but probably produces different results from what the local job produced. This is impossible to catch with the current checks.
Maybe one way would be to run athena with exactly the same settings (random numbers etc, extracted from log.generate) and then perhaps write a basic rivet routine (that the uploader should also provide for their local run). Maybe it's a bit too much but we should see how to avoid the above problem.
-
Check 421002 with new automatic script -
Check what happens when 421002 is added without the Sherpa_i
directory => Athena runs with no error -
Develop logic to avoid the situation reported here
log.generate_without_Sherpa_ilog.generate_with_Sherpa_i
@fsiegert can you tell from the log.generate files above which one was using Sherpa_i/2.2.6_BaseFragment.py
?
And how are we supposed to know if a user should or shouldn't upload an additional directory in a DSID directory?