DSID checking in commit script and CI
This MR introduces two changes:
- checking of DSID range in
commit_new_dsid.shand in CI
- suggestion of DSID range to use
Checking of DSIDs
commit_new_dsid.sh is run it will automatically loop over all jO that are added (specified with the
-d flag) and make sure that they are in the correct DSID range, as discussed in #29 (closed).
The DSID range checking is done via the
check_jo_consistency.py script, so one also performs all the naming checks at the same time.
Typically one would first run with
-n so one is supposed to rename the directories according to what the script suggest and then rerun the scripts with the correct DSIDs and eventually commit.
The CI check is incorporated in the
check_jo_consistency job, i.e. after this MR is merged one will not only check the jO for their naming but also make sure that they are in a directory in the correct DSID range.
Since this job is not allowed to fail we won't be accepting jOs if they don't live in the correct DSID range.
How the suggestion mechanism works
When doing the dry-run of the commit script the script will:
- loop over all DSIDs in the commit
- identify the jO in each DSID directory and extract the first generator
- query all the heads in
origin, find the min and max allowed DSID for the generator determined in (2) and return the minimum free DSID
- since the minimum free DSID is returned if there are "holes" in a DSID range, the suggested range will try to cover them, e.g. if
700000,700002are occupied and we ask to commit 3 new Sherpa jO the script will suggest
700001,700003,700004. As time goes by, this should happen less often if people stick to the suggestion of the script
- if a DSID to be committed is already in the correct DSID range, there is no ERROR thrown. In the above example, if
700000,700002are occupied and we put a new Sherpa DSID in
799999the script will not complain.
Closes #29 (closed)