# Mix-in definitions to inherit a standardized *rules* parameter.
# Reference:
# * https://docs.gitlab.com/ee/ci/yaml/#rules
# * https://docs.gitlab.com/ee/ci/variables/README.html#syntax-of-environment-variable-expressions

# GitLab CI uses a YAML array for the *rules* job parameter, but neither YAML
# nor GitLab CI syntax provide a way to merge arrays. However, elements of
# *rules* are mappings, and we can at least reduce the amount of copy-paste
# syntax by providing anchors and example arrays.
# The following YAML objects may be referenced through "anchors" as elements of
# the *rules* array in mix-in jobs (defined later in the file).
# The &<name> annotation is a YAML anchor that allows the annotated {"if", "when"} hash
# to be inserted with a *<name> alias in a `rules` arrays in the current file.
# Commonly reusable elements have anchors defined for easy copy-paste templating
# of new rule sets. Rule elements that are unique to a single *rules* mix-in may
# be defined with the rule set for readability, particularly when the element is
# the main distinguishing characteristic of the mix-in.

# Exclude from pipelines launched outside the "gromacs" GitLab project namespace.
.rules-element:if-not-gromacs-then-never: &if-not-gromacs-then-never
  if: '$CI_PROJECT_NAMESPACE != "gromacs"'
  when: never

# Exclude if the GROMACS_RELEASE variable is set.
.rules-element:if-release-then-never: &if-release-then-never
  if: '$GROMACS_RELEASE'
  when: never

# Exclude unless the GROMACS_RELEASE variable is set (through the web interface).
.rules-element:if-not-release-then-never: &if-not-release-then-never
  if: '$GROMACS_RELEASE == null'
  when: never

# Include in pipelines triggered through the web interface.
.rules-element:if-web-then-on-success: &if-web-then-on-success
  if: '$CI_PIPELINE_SOURCE == "web"'
  when: on_success

# Exclude from pipelines triggered by "push" events.
.rules-element:if-push-then-never: &if-push-then-never
  if: '$CI_PIPELINE_SOURCE == "push"'
  when: never

# Include in pipelines triggered by "push" events to any branch.
.rules-element:if-push-then-on-success: &if-push-then-on-success
  if: '$CI_PIPELINE_SOURCE == "push"'
  when: on_success

# Include in "schedule" pipelines (e.g. nightly jobs)
.rules-element:if-schedule-then-on-success: &if-schedule-then-on-success
  if: '$CI_PIPELINE_SOURCE == "schedule"'
  when: on_success

# Exclude from selective "schedule" pipelines, e.g. just those
# that should run the post-merge-acceptance jobs.
.rules-element:if-post-merge-acceptance-then-never: &if-post-merge-acceptance-then-never
  if: '$POST_MERGE_ACCEPTANCE'
  when: never

# Include in pipelines triggered in the merge request process.
.rules-element:if-mr-then-on-success: &if-mr-then-on-success
  if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
  when: on_success

# Exclude from pipelines triggered in the merge request process, such as for
# jobs that duplicate checks already performed for "push" events or that we
# only want to run in scheduled / manually triggered pipelines.
.rules-element:if-mr-then-never: &if-mr-then-never
  if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
  when: never

# Include job when running for merge request or when pushing to protected branch.
.rules-element:if-post-merge-acceptance-or-mr-then-on-success: &if-post-merge-acceptance-or-mr-then-on-success
  if: '$CI_PIPELINE_SOURCE == "merge_request_event" ||
       ($CI_PIPELINE_SOURCE == "push" &&
        $CI_COMMIT_REF_NAME == "master")'
  when: on_success

# Include job only for post submit push
.rules-element:if-post-merge-acceptance-then-on-success: &if-post-merge-acceptance-then-on-success
  if: '$CI_PIPELINE_SOURCE == "push" &&
       $CI_COMMIT_REF_NAME == "master"'
  when: on_success

# When composing a rule set, note that the first matching rule is applied.
# If you want later rules to be evaluated, you must make sure that the *if*
# clause of the earlier rules does not match. This may require inverting the
# logic of a rule element *if* and *when* clause in a new element definition
# (above) in order to construct new rule sets.

# Jobs that run for new commits and pipelines triggered by schedules or
# through the web interface, unless GROMACS_RELEASE is set. Excluded from
# extra pipelines generated by merge request events.
# Includes non-gromacs projects. Note that jobs using this rule are
# eligible to run on non-gromacs project infrastructure, and should therefore
# override the default *tag* parameter to exclude tags specific to the GROMACS
# GitLab Runner infrastructure. I.e. in the job definition, set `tags: []`
.rules:basic-push:
  rules:
    - *if-release-then-never
    - *if-mr-then-never
    - *if-post-merge-acceptance-then-never
    - *if-web-then-on-success
    - *if-push-then-on-success
    - *if-schedule-then-on-success

# Jobs to run after successful merge of a new commit.
# Only run on GROMACS infrastructure and only when merging into
# the master or release branches.
.rules:post-merge-acceptance:
  rules:
    - *if-not-gromacs-then-never
    - *if-release-then-never
    - *if-mr-then-never
    - *if-post-merge-acceptance-then-on-success
    - *if-web-then-on-success
    - *if-schedule-then-on-success

# Jobs that run for merge requests and schedules, but not when GROMACS_RELEASE
# is set. Excludes non-GROMACS projects.
# More elaborate rule sets for merge requests should be based on the same sequence.
.rules:merge-requests:
  rules:
    - *if-not-gromacs-then-never
    - *if-release-then-never
    - *if-push-then-never
    - *if-post-merge-acceptance-then-never
    - *if-web-then-on-success
    - *if-schedule-then-on-success
    - *if-mr-then-on-success

# Jobs running both in post submit and for merge requests
# Excludes non-GROMACS projects.
.rules:merge-and-post-merge-acceptance:
  rules:
    - *if-not-gromacs-then-never
    - *if-release-then-never
    - *if-web-then-on-success
    - *if-schedule-then-on-success
    - *if-post-merge-acceptance-or-mr-then-on-success

# Jobs that run for merge requests and schedules for branch `master`,
# but not when GROMACS_RELEASE is set.
# Excludes non-gromacs projects.
.rules:merge-requests:master:
  rules:
    - *if-not-gromacs-then-never
    - *if-release-then-never
    - *if-post-merge-acceptance-then-never
    - *if-web-then-on-success
    # This rule catches "push" and other events in branches other than `master`
    # but allows merge_request_events for merge requests targeting master.
    - if: '$CI_MERGE_REQUEST_TARGET_BRANCH_NAME != "master" && $CI_COMMIT_REF_NAME != "master"'
      when: never
    - *if-schedule-then-on-success
    - *if-mr-then-on-success

# Jobs that run for merge requests and schedules for branch `release-2021`,
# but not when GROMACS_RELEASE is set.
# Excludes non-gromacs projects.
.rules:merge-requests:release-2021:
  rules:
    - *if-not-gromacs-then-never
    - *if-release-then-never
    - *if-post-merge-acceptance-then-never
    # This next rule catches "push" and other events in branches other than `release-2021`
    # but allows merge_request_events for merge requests targeting `release-2021`.
    # This rule is before "web" so the web interface won't include jobs that can't succeed
    # (and would not ordinarily be run). Such jobs are hard to identify in a way that is
    # sufficiently general for a global rules definition.
    # If extra coverage is needed through a web-triggered job in merge request branches,
    # we could provide an additional short-circuiting rule based on an environment variable
    # to be provided through the web interface.
    - if: '$CI_MERGE_REQUEST_TARGET_BRANCH_NAME != "release-2021" && $CI_COMMIT_REF_NAME != "release-2021"'
      when: never
    - *if-web-then-on-success
    - *if-schedule-then-on-success
    - *if-mr-then-on-success

# Jobs that run for merge requests and schedules for branch `release-2020`,
# but not when GROMACS_RELEASE is set.
# Excludes non-gromacs projects.
.rules:merge-requests:release-2020:
  rules:
    - *if-not-gromacs-then-never
    - *if-release-then-never
    - *if-post-merge-acceptance-then-never
    # This next rule catches "push" and other events in branches other than `release-2020`
    # but allows merge_request_events for merge requests targeting `release-2020`.
    # This rule is before "web" so the web interface won't include jobs that can't succeed
    # (and would not ordinarily be run). Such jobs are hard to identify in a way that is
    # sufficiently general for a global rules definition.
    # If extra coverage is needed through a web-triggered job in merge request branches,
    # we could provide an additional short-circuiting rule based on an environment variable
    # to be provided through the web interface.
    - if: '$CI_MERGE_REQUEST_TARGET_BRANCH_NAME != "release-2020" && $CI_COMMIT_REF_NAME != "release-2020"'
      when: never
    - *if-web-then-on-success
    - *if-schedule-then-on-success
    - *if-mr-then-on-success

# Rule to run a job only in nightly release-preparation pipelines.
# Checks if the GROMACS_RELEASE variable was set (typically through the GitLab web interface).
# Excludes merge_requests and non-gromacs projects.
.rules:nightly-only-for-release:
  rules:
    - *if-not-gromacs-then-never
    - *if-not-release-then-never
    - *if-post-merge-acceptance-then-never
    - *if-web-then-on-success
    - *if-schedule-then-on-success

# Jobs that run on schedules, but not for merge requests or when GROMACS_RELEASE
# is set. Excludes non-gromacs projects.
.rules:nightly-not-for-release:
  rules:
    - *if-not-gromacs-then-never
    - *if-release-then-never
    - *if-post-merge-acceptance-then-never
    - *if-web-then-on-success
    - *if-schedule-then-on-success