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 likemcXX.*.py
-
check_jo_consistency
: no diff-filter but triggered bychanges: "[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
incheck_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 likemcXX.*.py
with adiff-filter=AMCRT