Once #3071473: Add a create fork / workspace button to issues is done, issues on Drupal.org should have some information about activity in the issue’s fork. Once we are on to #2205815: Merge requests in Drupal.org issue queues?, merge-request-related activity will be figured out in a followup issue.
At minimum, I imagine this would be a note of which branches exist. At maximum, every commit.
I suspect we should be more minimal here. Until the merge request is open, the analogue of posting a patch, every commit is essentially a draft. The history will be available by clicking over to the repository on git.drupalcode.org.
For implementation, this might be pulled in client-side from GitLab’s API, pulled in server-side from GitLab’s API, or pushed to Drupal.org’s DB by a post-commit hook.
User interface changes
Fork information
- Issue fork name ✅ done
- Clone / get push access ✅ done
- #3071474: Add prompts to get a Git account to issues
- Link to detailed instructions ✅ done
- #3071746: Create branch in issue fork button?
For each active branch
- Branch name ✅ done
- Compare link, with nearest branch that exists in the project - As in a core 9.0.x-dev issue will usually be compared with 9.0.x, where it was branched from. The same issue might have other branches made from 9.1.x/8.9.x/etc. ✅ done
- Last commit made ✅ done
- Link to merge request raw diff, when available
- Likely, if possible - How many comments have been made on lines of code in the branch’s commits, linking to a listing of those comments.
- Maybe - Who has committed on the branch. (The most recent committer is straightforward to pull in.)
- Maybe - When the last commit made on the branch.
- Maybe, less likely - How many commits were made on the branch.
Issue fork drupalorg-3071681
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
hestenetThinking about this in terms of use cases - what are the use cases where you want some kind of activity posted back to the issue, before a merge request is open?
Comment #3
hestenetComment #4
drummComment #6
hestenetAs we've discussed this internally, there are a few kinds of information we'd like to have available back on the Drupal.org issue:
For issue forks:
For merge requests:
Comment #11
drummAdding a draft listing of what we have, and have talked about adding, to the issue summary. There’s an example of what we have now in this issue’s sidebar. I’d like to keep merge-request-related information to followup issues when we get #2205815: Merge requests in Drupal.org issue queues? moving.
When there’s more information than can be fit into the sidebar, we can move it to the main content area, above the “Add new comment” form would be a straightforward block move. This might fit better below the files listing in the issue summary, and above the comments.
I did have to create a DB table to track “active” branches, since forks come with all of the upstream repository branches. After forking, any branch that’s been pushed to gets listed. We have space to archive/hide stale branches, somewhat like we can hide files.
Comment #13
drummThe issue fork block now links to https://www.drupal.org/drupalorg/docs/gitlab-integration/issue-forks-mer...
Comment #16
drummThere is now a compare link for every branch, which compares it with the issue’s branch, as in 7.x-1.x for 7.x-1.x-dev, or 1.2.x for 1.2.2. If the issue doesn’t have a version (no releases are made yet), that falls back to the repository’s default branch.
The rest of this issue is currently covered by other issues, or is likely/maybe. Un-assigning myself for now as work will continue in the other issues.
Comment #17
mglamanAdding my thoughts: having the commit comments in the issue would be helpful. It would help "bump" issues that maybe are not receiving comments, but are having work down. (see #14, #15.) And that could link to the GitLab commit, making it easy to go and review.
Comment #19
drummFrom voleger in #3152637-51: Opt-in to the Drupal.org Issue Forks and Merge Requests beta:
Comment #20
MixologicWorth noting that there is no way to download patches of arbitrary compares in gitlab. Only once there is a full MR is that possible.
We do already have this compare on the branch listing now.. but yeah I see what he means where a commit being pushed to a branch is essentially the delta from the last change, as well as the entirety of the delta. -> might still have to see how that works if somebody pushes a rash of small commits at once, for example.
Comment #21
drummWe now have this with the notes pulled in from GitLab. These don’t bump the issue updated date though. I’m hoping people develop a convention of commenting on the issue to summarize work when they are done for now. Issue still need to be updated manually to change their issue status, which should help encourage people to do this.
We only get commit notes when the branch has a merge request open. Once the merge request is open, any of the MR or merge request links will go to GitLab, which has the Changes tab. Or the compare link will go directly to the Changes tab.
A merge request’s commit notes link to the commit.
So far, which upstream branch an issue fork branch is targeting is not trivial to get, until a merge request is opened. The merge request does have the target branch metadata. Otherwise, we’re stuck walking though the commit parents.
There have been a few requests to link to the raw merge request patch. I’m not aware of an issue being open for that yet. We can do that here.
Comment #24
drummThere is now a link to the plain diff for each merge request. I think we can call this issue done, and consider additional UI additions/changes in smaller issues.