Commit status repository requirement is inconsistent

Currently, commit statuses must be posted to the source project to affect the status of an MR, but to the target project to appear in the Commits tab. Could the MR status look at both the source and target projects? Without that, our CI tool needs either admin rights over the entire instance or to be granted Reporter in all relevant forks.

Hi @ben.boeckel,

First of all, thank you for raising an issue to help improve the GitLab product. We're sorry about this, but this particular issue has gone unnoticed for quite some time. To establish order in the GitLab-CE Issue Tracker, we must ensure that every issue is correctly labelled and triaged, to get the proper attention.

This issue will be closed, as it meets the following criteria:

• No activity in the past 4 months
• Unlabelled
• Unassigned
• It's not associated with a particular milestone

We'd like to ask you to help us out and determine whether this issue should be reopened.

If this issue is reporting a bug, please can you attempt to reproduce on the latest version of GitLab or GitLab.com, to help us to understand whether the bug still needs our attention.

If this issue is proposing a new feature, please can you verify whether the feature proposal is still relevant.

Thanks for your help

Added ~761915 label

Status changed to closed

This is still a problem. We use a fork-based workflow and not being able to set commit statuses which show up in the MR means that our CI needs developer access to all forks to be able to set checkmarks. It'd be nice if we could have the checkmarks be looked up via the target repository.

@ben.boeckel Thanks again for your help here.

@ayufan Please could you take a look?

Status changed to reopened

Added ~19173 label

Removed ~761915 label

@godfat Could you take a look?

This is where we show the commit status for commits tab in a merge request: app/views/projects/merge_requests/show/_commits.html.haml, which has this line:

= render "projects/commits/commits", project: @merge_request.project

And MergeRequest#project is MergeRequest#target_project. I believe this should be correct. However, I can't find where we're showing the commit status in the main merge request page. It seems to be handled by some JavaScript manipulating CSS display:none. There, I think it's probably using MergeRequest#source_project, and which should be changed to MergeRequest#target_project.

This should be an oversight and considered a bug.

Added ~12980 ~13921 labels

I can't identify where the exactly code is for showing that CI status, but I feel it might have something to do with MergeRequest#pipeline. I am checking where we set it for the merge request.

Oh, silly me. I should have remembered. MergeRequest#pipeline was:

def pipeline
  return unless diff_head_sha && source_project

  @pipeline ||= source_project.pipeline_for(source_branch, diff_head_sha)
end

Which for source_project should be correct. It's that above @merge_request.project wrong, it should also be @merge_request.source_project.

Mentioned in commit d2a9eefb

Mentioned in merge request !6658 (merged)

@ben.boeckel Could you please confirm if !6658 (merged) would fix it? Thanks!

@ben.boeckel Umm... You said that you want this be shown in target project (https://gitlab.com/gitlab-org/gitlab-ce/issues/3596#note_16101164), and I could understand this is due to some admin issue. But I think we're using source project everywhere else, and that makes more sense to me. So would setting it to source project works for you? At least it's more consistent?

Reassigned to @godfat

The problem with permissions is that we need to add our CI (a buildbot instance) to the member list for the source project in order to be able to post it there. Currently, since we already have an admin account, we just have it add our CI to all projects upon creation for future proofing, but if we only had to add it to the projects which has CI hooked up (i.e., non-fork projects), it'd be cleaner in that regard.

Currently, you couldn't do a setup like this on gitlab.com (unless you gave out admin accounts upon request, something I'd hope would just be an instant "no" :) ) because people would have to add the CI bot to the forks manually for the commit status badges to appear on the MR page at all. Maybe it could look up statuses from either the source project or the target project?

Yes, I agreed that it's certainly an issue for a forking workflow. I found the same issue at #12926 (moved). However I don't think that showing it from either source project or target project makes a lot of sense. It would be somehow inconsistent between each merge request and make it hard to understand, and could be surprising. Neither showing both of them do make much sense to me. They're just different and would make the UI difficult.

I think the real solution here is actually #20690 (moved), that means using the runners in target project and show the status/commits for that pipeline. I think that's the real culprit here. Could you confirm if doing that would work for you?

(Unfortunately we don't yet know how to do that properly)

As long as things are not tied to .gitlab-ci.yml and the target project can be used for status badges, I'm fine with the mechanisms :) .

We'll try to tackle that in #20690 (moved). I'll just take this issue to fix the inconsistency you mentioned then. Thanks for the feedback!

Milestone changed to %8.14

Status changed to closed by commit d2a9eefb

Status changed to closed by merge request !6658 (merged)

Mentioned in commit pfjason/gitlab-ce@ba27abec

Mentioned in issue #22106 (moved)

mentioned in issue #2456 (moved)