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

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

Command icon 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:

About issue forks
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

drumm created an issue. See original summary.

hestenet’s picture

hestenet
He/Him
Location Portland, OR 🇺🇸
CreditAttribution: hestenet at Drupal Association commented

Thinking 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?

  • I am a user thinking about jumping in to help - I want to know if someone is already actively working on it
  • Anything else?
hestenet’s picture

hestenet
He/Him
Location Portland, OR 🇺🇸
CreditAttribution: hestenet at Drupal Association commented
Issue tags: +mwds2019
drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm at Drupal Association commented
Assigned: Unassigned » drumm
Status: Postponed » Active

  • drumm committed 18ba2ca on 7.x-3.x 
    Issue #3071681: Add git remote URLs
hestenet’s picture

hestenet
He/Him
Location Portland, OR 🇺🇸
CreditAttribution: hestenet at Drupal Association commented

As 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:

  • What issue forks(branches) exist for this issue
  • An option to create a new one
  • An option to 'get access' to an existing one
  • The timestamp of last activity on the issue fork
  • Maybe: the number of commits
  • No automated comments, because until the merge request is opened there's likely to be a lot of noise that is not ready for review as contributors commit as they go.

For merge requests:

  • Next to the relevant issue fork(branch) - an indication that a merge request exists
  • As an automated comment: that a merge request has been opened
  • As an automated comment: that a merge request has been closed (accepted or rejected)
  • The timestamp of last activity on the merge request
  • # of commits in the merge request
  • Maybe: Indicator of new comments on the merge? (using gitlab code review tools)
  • Maybe: Indicator of commits since the merge was opened (maybe these should get automated comments?)

  • drumm committed b58ca3f on 7.x-3.x 
    Issue #3071681: Link to active branches in an issue fork

  • drumm committed f4fd472 on 7.x-3.x 
    Issue #3071681: Add the last commit

  • drumm committed 5e4cc03 on 7.x-3.x 
    Issue #3071681: Label the Git remote URL as what it is

drumm credited Mixologic.

drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm at Drupal Association commented
Issue summary: View changes
Related issues: +#3071474: Add prompts to get a Git account to issues, +#3071746: Create branch in issue fork button?

Adding 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.

  • drumm committed 42d926f on 7.x-3.x 
    Issue #3071681: Add link to documentation
drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm at Drupal Association commented
Issue summary: View changes

The issue fork block now links to https://www.drupal.org/drupalorg/docs/gitlab-integration/issue-forks-mer...

  • drumm committed a82498b on 7.x-3.x 
    Issue #3071681: Only show the “About issue forks” if there is a...

  • drumm committed 921b9c9 on 7.x-3.x 
    Issue #3071681: Add compare icon
  • drumm committed a5f4fb2 on 7.x-3.x
    Issue #3071681: Add compare link
drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm at Drupal Association commented
Assigned: drumm » Unassigned
Issue summary: View changes

There 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.

mglaman’s picture

mglaman
Primary language English
Location WI, USA
CreditAttribution: mglaman at Centarro commented

Adding 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.

drumm credited voleger.

drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm at Drupal Association commented

From voleger in #3152637-51: Opt-in to the Drupal.org Issue Forks and Merge Requests beta:

Also noticed that would be helpful to have two links on the commit comment message:

  • first is the link to the diff on Gitlab UI between commit and source repo branch; No glue for now how to generate the link to the diff without merge requests enabled.
  • another link available if it's not the first commit. This link will follow the user to the diff page between the commit and previous commit within the forked repo. https://git.drupalcode.org/issue/{fork_id}/-/compare/{previous_commit_hash}...{commit_hash}

So in the result the commit comment message would be provided automatically with two diffs

  • first diff will show the compatibility with upstream branch, and it woul be actual patch if no conflicts would be provided. So that patch can be downloaded from the Gitlab UI and uploaded to the issue be page for the testing purposes.
  • second - classic interdiff between the patches commits
Mixologic’s picture

Mixologic
He/Him/His
Primary language English
Location Portland, OR
CreditAttribution: Mixologic at Drupal Association commented

first diff will show the compatibility with upstream branch, and it woul be actual patch if no conflicts would be provided. So that patch can be downloaded from the Gitlab UI and uploaded to the issue be page for the testing purposes

Worth 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.

drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm at Drupal Association commented
Assigned: Unassigned » drumm
Issue summary: View changes

Adding 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.

We 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.

first is the link to the diff on Gitlab UI between commit and source repo branch; No glue for now how to generate the link to the diff without merge requests enabled.

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.

another link available if it's not the first commit. This link will follow the user to the diff page between the commit and previous commit within the forked repo. https://git.drupalcode.org/issue/{fork_id}/-/compare/{previous_commit_hash}...{commit_hash}

second - classic interdiff between the patches commits

A merge request’s commit notes link to the commit.

first diff will show the compatibility with upstream branch, and it woul be actual patch if no conflicts would be provided. So that patch can be downloaded from the Gitlab UI and uploaded to the issue be page for the testing purposes.

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.

  • drumm committed 03175c1 on 7.x-3.x 
    Issue #3071681: Add title attribute to compare links

  • drumm committed c3904ed on 7.x-3.x 
    Issue #3071681: Link to plain diff
drumm’s picture

drumm
he/him
Location NY, US
CreditAttribution: drumm at Drupal Association commented
Status: Active » Fixed

There 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.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.