This change updates the text of the pipeline widget that appears on the
merge request page. The text has been made more consistent between
different types of pipelines; this makes the front-end implementation
simpler and more maintainable. In addition, the type of pipeline is
(i.e. regular pipeline, merge request pipeline, detached pipeline)
included in the text, making this type more obvious to the end user.
Some information has been removed from the widget as part of this
change; however, any information that was removed already appears
elsewhere on the merge request page.
This commit adds a helper text that describes what will happen when a
user clicks the "Start/Add to merge train when pipeline succeeds"
button. This text appears at the bottom of the merge request widget.
In addition, this commit renames the "merge_train_info" component to
"merge_train_position_indicator" to avoid ambiguity with the
"merge_train_helper_text" component.
This commit fixes an issue that was causing the merge button dropdown
trigger to be shown even if the dropdown itself was hidden. This commit
also fixes an issue that caused the "Merge Immediately" option not to be
available when merge trains were enabled.
New API endpoint for merge request count
Updates all open tabs at the same time with one call
Restructured API response
API response changed to 401 if no current_user
Added API + JS specs
Fix for Static Check
Updated Count on Open/Close, Assign/Unassign of MR's
Checking if MR Count is refreshed
Added # frozen_string_literal: true to spec
Added Changelog
This commits extracts /merge_requests/1.json?serializer=widget
Into a separate /merge_requests/1/widget.json endpoint
This will allow to use caching for this request
Previously the frontend assumed that the user had to be able to merge to
that project in order to resolve conflicts. However, this is overly
restrictive, as the user only has to be able to push to the source
branch. In fact, appending the text /conflicts to the merge request
would bring up the conflict resolution page.
This confusion happens when a project contains a protected branch that
only allows maintainers to push. Users with Developer access no longer
have permission to merge, but they still can create branches in that
project.
To fix this issue, we now loosen the permission check for the "Resolve
conflicts" button and only check for access to push to the source
branch. This is consistent with what the backend does in
MergeRequests::Conflicts::ListService#can_be_resolved_by?.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/47954
We have one auto merge strategy today - Merge When Pipeline
Succeeds.
In order to add more strategies for Merge Train feature,
we abstract the architecture to be more extensible.
Removed arguments
Fix spec
GitLab Bot
Nathan Friend
Paul Slaughter
Illya Klymov
Igor
Ezekiel Kigbo
Tanya Pazitny
Lukas 'Eipi' Eipert
Tim Zallmann
Michel Engelen
Ash McKenzie
Filipa Lacerda
Mike Greiling
Kamil Trzciński
Fatih Acet
Lin Jen-Shin
Stan Hu
Shinya Maeda
Mike Scott
Sarah Groff Hennigh-Palermo
George Tsiolis