Development model, CI triggering and refining of diff-filters

  • Define different triggers for jobs that can be skipped
  • Define branches on which jobs will run
  • Can we allow everyone to be a developer since the master is protected?
  • Refine diff-filter

Job triggering

Allow for different triggers for jobs that can be skipped, so that users can adjust which jobs to run. We should also see on which branches the pipelines will run.

Development model

Switching to a development model where everyone uses branches is necessary since some pipelines (check_logParser and later the athena jobs) rely on hidden variables (mcgensvc password etc) that should not be visible to normal users. This means that if a user would fork the repository the variables would not be copied and the CI jobs would fail.

Since master is protected probably we can allow users to be developer, as done by other ATLAS packages.

Refining of diff-filter

We currently have the following diff-filters:

  • check_unique_physicsShort: diff-filter=A | grep -E "mc[0-9]{2}.*py"
  • check_modified_files: diff-filter=MDCRTUXB
  • check_logParser: diff-filter=AMDCRTUXB and files must be named like mcXX.*.py
  • check_jo_consistency: no diff-filter but triggered by changes: "[0-9][0-9][0-9]xxx/**/mc[0-9][0-9].*.py"

legend:

# Copied (C), Deleted (D), Modified (M), Renamed (R), have their type
# (i.e. regular file, symlink, submodule, …​) changed (T), are Unmerged (U),
# are Unknown (X), or have had their pairing Broken (B).

The following perhaps need to be revised:

  • not clear to me that we need UXB in check_logParser
  • for check_jo_consistency triggering on any change in the DSID directories is probably too much. We should perhaps restrict this to only files named like mcXX.*.py with a diff-filter=AMCRT
Edited by Spyros Argyropoulos