The source project of this merge request has been removed.
add a few methods to help interacting with CI status
related to #6
this adds pipeline_status
which returns the status of CI for the current MR (success, failed or running), as well as some methods to know when the bot interacted with a MR. These are useful for #6 as they allow the bot to not simply spam "I'm not assigning someone because CI is failing" every hour.
These methods are currently not used. Below is a sample policy that would assign only when CI succeed, and print a message when it's not assigning due to CI error, limiting this message to at most one per CI failure, and at most one every two days.
resource_rules:
# These rules only applies to Merge Requests.
merge_requests:
rules:
# We give each rule a name that let's us find it in the logs later.
- name: Assign reviewers to all MR's with no reviewers and passing CI.
# All conditions must evaluate to true before the actions are going to
# be executed.
conditions:
# See src/tor.rb for how this function is defined. Return true
# iff the given MR have a reviewer assigned, otherwise false.
ruby: |
!has_reviewer? && pipeline_status == "success"
# We only look at open tickets.
state: opened
# Execute all of the actions if all of the above conditions are satisfied.
actions:
# We use Gitlab's Quick Actions to randomly assign the MR to
# someone in the network team who is not the author of the MR.
comment: |
/assign_reviewer @#{ random_reviewer(["eta", "Diziet", "nickm"]) }
- name: Warn failing CI.
conditions:
ruby: >
!has_reviewer? && pipeline_status == "failed" &&
bot_last_interacted < pipeline_end_time &&
bot_last_interacted < (DateTime.now - 2)
state: opened
actions:
comment: |
it looks like CI is failing :confused: