Change how build failure comments are generated

[kwk]

1. Upon issue creation we create minimized comments for all chroots and
   mark them with i.e. <!--ERRORS_FOR_CHROOT/fedora-rawhide-x86_64-->.
2. When we find an error in a chroot we update the above created comment
   and unminimize it.
3. In case when there's no error for a chroot, we're gonna minimize the
   comment again.

Fixes #626

[nikic]

It would be good to address this part of the issue at the same time:

When doing that, we should also only set the assignee after posting these comments. That way the maintainer will only receive one notification per day, rather than one per failed build.

Otherwise whoever is maintainer will get ~20 not very helpful emails for empty comments (unless GitHub suppresses them in this case?)

[kwk]

It would be good to address this part of the issue at the same time:

When doing that, we should also only set the assignee after posting these comments. That way the maintainer will only receive one notification per day, rather than one per failed build.

Otherwise whoever is maintainer will get ~20 not very helpful emails for empty comments (unless GitHub suppresses them in this case?)

@nikic I've made the change as you suggested. We'll have to ask @tuliom tomorrow if he got more than one notification.

[nikic]

Thanks! I think an adjustment to initial_comment may also be needed, as that also uses maintainer_handle ping (and thus subscribes by mail to the issue). I think it's fine to just drop the "hi" there :)

[nikic]

LGTM, thanks!

[nikic]

I got 14 empty notifications todays :) It seems like there is a bit of a race condition on GitHub's side, so if a lot of actions are taken in a short time frame, it may end up sending notifications for stuff that happened before you subscribed to the issue.

This can probably be "fixed" just by waiting for a minute before doing the assignment...

[kwk]

I got 14 empty notifications todays :) It seems like there is a bit of a race condition on GitHub's side, so if a lot of actions are taken in a short time frame, it may end up sending notifications for stuff that happened before you subscribed to the issue.

I feared this because Github certainly does so when assigning and removing labels. It groups the actions together it seemed.

This can probably be "fixed" just by waiting for a minute before doing the assignment...

How about assigning the maintainer only on the second run of the checks like done in #643? The second run is still way to early to expect any results anyways.