Reusable notification workflow

[samwinebrake]

This PR has a couple new features:

• new reusable workflow .github/workflows/user_notification_system.yml with two capabilities
  • extract user emails from both web submissions and non-web submissions
  • failure notification system
• failure check and email function in brainscore_vision/submission/actions_helpers.py
• trigger of failure notification system whenever any check fails in .github/workflows/check_if_pr_is_automergeable.yml
• use of new email extraction workflow in .github/workflows/score_new_plugins.yml that passes correct email on to Jenkins

Closes issue #80 in core.

NOTE:

• In the future, these workflows will be moved to core in order to allow for centralized github actions.
• The past Travis notification system will be removed by hard release.

[mschrimpf]

@kvfairchild knows github actions much better than me, will defer to her review

[kvfairchild]

As written, this has the potential to send a LOT of duplicate failure notification emails; for instance, if the first test suite fails, the user will receive the exact same failure email for every subsequent status update, regardless of whether or not those test suites pass. Suggest only sending email for first detected failure.

[samwinebrake]

Example of failure-notified label shown here (simulating an automerge-web submission that fails tests). When tests fail, the user is emailed and a failure-notified label is added to the PR. I then removed the failure-notified label and re-added it to ensure that testing is skipped when a failure-notified label is added (so that we don't overrun this workflow when an initial failure-notified is added). Lastly, I pushed a new change to the PR showing that the github-actions bot will remove the failure-notified label with new changes. It then emails the user about this new failure wrt the new PR, and readds the failure-notified label. When no changes have occurred to an already failing PR but a new check has failed, the notification workflow will be skipped due to the presence of the failure-notified label.

@kvfairchild does this address your concerns?

[kvfairchild]

Assuming this has been thoroughly tested, LGTM!

[kvfairchild]

Don't changes to open PRs automatically result in CI checks?

[kvfairchild]

Suggested change

	# - updates to current PRs
	# - updates to current PRs ("synchronize" events)