GitHub Comment Coalescing

[grahamc]

Ofborg is growing a nice feature set, and with it more things to say on every issue. With two-to-three comments per issue, I think we're at risk of sending too much noise.

One solution is to coalesce replies in to a single comment. This would ideally be one comment per call, not one comment per issue. In other words, if there are two calls on the issue:

this would result in two comments, one per call.

what I'd do once we have this

• Update the issue to say the commands were received and where they will run
• Update the issue when a build starts running (already can be known via the logs exchange)
• Provide a link to the log viewer

down sides

• GitHub doesn't properly propagate comment updates sometimes when the page is already loaded, so maybe people will feel they aren't getting feedback because they don't see anything changing
• GitHub's comments isn't a transactional database and so if there are multiple poster jobs running simultaneously, comments could be easily lost. Additionally, updates could easily be lost if there is replication lag or cache problems on GitHub.

implementation details

• when a job is scheduled in the githubcommentfilter job, we should generate a call_id and pass that to the build job
• the builder should include call_id in the BuildLogStart message
• when a build is finished, the builder should include the call_id in the BuildResult message
• the poster job should be rewritten in Rust first
• the poster job should include the call ID in each comment it leaves
• the poster job should look for an existing comment with the call ID and append its message to the end

[layus]

Just a random idea here: Would it be possible to use PR status for this. Triggering a build would just add new tests with their status to the PR. You could even create entries that remain 'pending' while not triggered by an authorized user. The message of these tests could even be an url to trigger the build, so the messages "@GrahamcOfBorg XXX" would also be removed from the conversation.

[layus]

Just a random idea here: Would it be possible to use PR status for this. Triggering a build would just add new tests with their status to the PR. You could even create entries that remain 'pending' while not triggered by an authorized user. The message of these tests could even be an url to trigger the build, so the messages "@GrahamcOfBorg XXX" would also be removed from the conversation.

[7c6f434c]

Is there any API for removing comments from the discussion that allows only removing own comments? If yes, maybe build could post a new comment that has all the previous builds in a collapsed section, and remove the old comments? If no, well, playing with comment removal is scary without a safety net.

[7c6f434c]

Is there any API for removing comments from the discussion that allows only removing own comments? If yes, maybe build could post a new comment that has all the previous builds in a collapsed section, and remove the old comments? If no, well, playing with comment removal is scary without a safety net.

[grahamc]

I'm not going to do this.

[grahamc]

I'm not going to do this.

[vcunat]

The comments might now be movable to the new "checks" tab, separating the noise from actual discussion: https://help.github.com/articles/about-status-checks/#checks

[vcunat]

The comments might now be movable to the new "checks" tab, separating the noise from actual discussion: https://help.github.com/articles/about-status-checks/#checks