When #3071752: Enable ability to open merge requests for branches in issue forks is done, activity on the merge requests should be discoverable. See also #3071681: Decide what information about issue forks to show on issue page on Drupal.org, implement.
An automated comment on the Drupal.org issue, setting the issue to needs review, to alert the maintainer about activity would be good. Ongoing comments for merge request activity would also be good, but overkill if it were alerting for comments on individual lines of code.
We can also pull in information client-side or server-side from GitLab’s API as the issue is viewed. We need to explore the options for GitLab to push notifications of merge request activity to www.drupal.org, or poll for updates.
Issue fork drupalorg-3071755
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
drummComment #3
drummPre-merge request opening, comments can be made on commits. These are at pages like https://git.drupalcode.org/issue/drupalorg-3071681/activity, the Comments tab.
That GitLab page which does make XHR requests to get that HTML in JSON. It is not part of the API, and I assume could change in any GitLab release. That looks like the only way to efficiently list all comments in an issue fork.
The REST API does have these comments available, https://docs.gitlab.com/ee/api/discussions.html#list-project-commit-disc..., but only for individual commit hashes.
The GraphQL API does not have these that I can find.
Comment #4
drummPost-merge request opening, comments on the merge request and commits in it, including comments made before merge request opening, look like they are easily available via Rest https://docs.gitlab.com/ee/api/discussions.html#list-project-merge-reque... and GraphQL https://docs.gitlab.com/ee/api/graphql/reference/#mergerequest
Comment #5
drummThere is a webhook for that: https://docs.gitlab.com/ee/user/project/integrations/webhooks.html#merge...
Comment #7
drummFor comments we pull in, we should show the full text of the comment. There is an API to render Markdown, if we need it, https://docs.gitlab.com/ee/api/markdown.html. Complex GitLab-flavored Markdown, like suggested code changes, will be interesting.
Comment #8
MixologicFor *pre* merge request comments, I still feel like those should be Work in Progress, and not necessarily a place to collaborate. Unless we *do* want more pre-test collaboration to take place.
I guess the alternate argument is we dont want people to accidentally shout into a well without anybody else seeing it...
Comment #9
drummShouting into a well was my concern, commenting on an in-progress branch’s commit is useful collaboration. I don’t think we’ve actually opened an issue to allow GitLab to send notification emails yet, so here it is #3154890: Allow GitLab to send email notifications.
Comment #15
drummThis is to the point where the basics are done, and the rest of the work would benefit from separate followups. Two I already have are: