Setting gerrit notification message imprtance

[Igor]

Hello,

I wonder whether it is possible to use gerrit mail templates to set message importance to a non-default value. What I'm trying to do is to mark CI build failures as high importance messages.

I noticed in gerrit documentation a variable $messageClass, but when trying to use it in template gerrit produced an error:

com.google.template.soy.error.SoyCompilationException: errors during Soy compilation

/home/gerrit2/review_site/etc/mail/CommentHtml.soy:69: error: Unknown data key 'messageClass'.

    Message class is: {$messageClass}

This log is from v2.14.

Thanks in advance,

Igor.

[Martin Fick]

On Tuesday, May 23, 2017 01:46:25 AM Igor wrote:
> Hello,
>
> I wonder whether it is possible to use gerrit mail
> templates to set message importance to a non-default
> value. What I'm trying to do is to mark CI build failures
> as high importance messages.

<prefernece opinion>
Not sure if it is possible, but I highly advise against that
unless you want many enemies. Most people want to filter
these straight to SPAM, so marking them high importance is
likely to ruffle a lot of feathers. Just my personal $.02...
</prefernece opinion>

-Martin

--
The Qualcomm Innovation Center, Inc. is a member of Code
Aurora Forum, hosted by The Linux Foundation

[Jan Kundrát]

On úterý 23. května 2017 17:01:23 CEST, Martin Fick wrote:
> Not sure if it is possible, but I highly advise against that
> unless you want many enemies. Most people want to filter
> these straight to SPAM, so marking them high importance is
> likely to ruffle a lot of feathers. Just my personal $.02...

I second that. You are already using Gerrit and CI, so presumably your
configuration is such that the CI sets Verified: -1 which blocks
submission.

In this scenario, a blocked patch is *not* a high-importance problem at all
because no harm has been done. The CI has done its job. There's no failure
potentially blocking other people's work because the CI stopped the faulty
patch prior to its merging.

In fact, we're revoked the "email reviewers" ACL bit from our CI. In our
workflow, it's the responsibility of the patch author to get the patch past
the CI. We therefore decided that it's better to let CI mail *just* the
owner of the change and not all reviewers. I for one do not want to hear
about someone's unusable patch -- I want to review it only once the CI
infrastructure did the trivial work for me.

With kind regards,
Jan

--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/

[Igor]

Thanks Martin and Jan for sharing your thoughts.

Igor.