| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
This reverts commit a82a595728d54bdc12e51dfcfb22e9eddc449143, reversing
changes made to e7df959b8f99875edd246c7ac7779c3203e8755e.
|
| |\
| |
| |
| |
| |
| |
| | |
Allow to add patches to merge requests created via email
Closes #40830
See merge request gitlab-org/gitlab-ce!22723
|
| | |
| |
| |
| |
| |
| | |
Sometimes we don't want to trigger any quick actions that cause side
effects. For example when building a record to validate. This allows
listing the quick actions that need to be performed.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This allows users to add patches as attachments to merge request
created via email.
When an email to create a merge request is sent, all the attachments
ending in `.patch` will be applied to the branch specified in the
subject of the email. If the branch did not exist, it will be created
from the HEAD of the repository.
When the patches could not be applied, the error message will be
replied to the user.
The patches can have a maximum combined size of 2MB for now.
|
| |/
|
|
|
| |
'master'"
This reverts merge request !22526
|
| |\
| |
| |
| |
| | |
Comment on any expanded diff line on MRs
See merge request gitlab-org/gitlab-ce!22398
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In EE, there is need to call `merge_requests_for_source_branch`
before calling CE's `refresh_merge_requests,
in order to obtain the old diffs.
However that requires `@push`,
initialized inside CE's refresh_merge_requests.
However it can't be set early in EE, or static analysis would fail
because use of instance variables in module is discouraged.
So @push is set in execute instead.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously for a given merge request, we would:
1. Create the array of commit SHAs involved in the push (A)
2. Request all merge request commits and map the SHA (B)
3. Reload the diff if there were any common commits between A and B
We can avoid additional database querying and overhead by
checking with the database whether the merge request contains any
of the commit SHAs.
Relates to https://gitlab.com/gitlab-org/gitlab-ce/issues/53213
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
|
|
| |
By preloading certain models with the diff, we can eliminate many N+1
queries. For a push to the staging GitLab.com www-gitlab-com repository,
this eliminates over 3000 SQL queries and appears to bring down the RSS
usage by several gigabytes.
Relates to https://gitlab.com/gitlab-org/gitlab-ce/issues/49703
|
| |\
| |
| |
| |
| |
| |
| | |
Fix extra merge request versions created from forked merge requests
Closes #53153
See merge request gitlab-org/gitlab-ce!22611
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When a forked merge request was created with the same branch name as the
target name, MergeRequests::RefreshService would always create a new
diff even though nothing had changed. For example, on GitLab.com:
1. There were a number of merge requests in the gitlab-ce and www-gitlab-com
projects that had old merge requests from the community.
2. These merge requests originated from forked projects and used the
source branch master.
3. When someone pushed to master in the main repository, MergeRequests::RefreshService
would see that master matched the merge requests in question and generated a new
diff.
4. This led to an explosion of merge request diffs and slowed down the "Changes"
tab considerably.
This change alters MergeRequests::RefreshService so that it will only
refresh the diff if the merge request's source project and branch
match. Otherwise, the refresh will only happen if a pushed commit
contains a commit relevant to the existing merge request.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/53153
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
Make new merge request URL more friendly when pushing code
Closes #53012
See merge request gitlab-org/gitlab-ce!22526
|
| | | |
|
| |/
|
|
|
| |
Move access checks to their own method so they can be overridden, and
port an EE-only method to exist in CE too, with an EE-specific override.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This whitelists all existing offenses for the various CodeReuse cops, of
which most are triggered by the CodeReuse/ActiveRecord cop.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| | |
'master'
Write diff highlighting cache upon MR creation (refactors caching)
Closes #50204
See merge request gitlab-org/gitlab-ce!21489
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Partially addresses #47424.
|
| | |
|
| |\
| |
| |
| |
| | |
Add extra logging to githost.log when rebasing
See merge request gitlab-org/gitlab-ce!20202
|
| | | |
|
| |/
|
|
| |
We should mark the MR as merged as first thing on PostMergeService as in practice it is already merged on the repository. Happens that errors may happen when executing external services such as Issues::CloseService, and we do not want a MR hanging as opened because of that.
|
| | |
|
| | |
|
| |
|
|
| |
from Tag)"
|
| |
|
|
|
|
| |
branch"
"Maintainer" will be freed to be used for #42751
|
| | |
|
| |\
| |
| |
| |
| | |
CE: Extract EE specific files/lines for some merge requests files
See merge request gitlab-org/gitlab-ce!19107
|
| | | |
|
| |/
|
|
|
|
|
|
| |
Old behavior of creating TODO when
“Merge When Pipeline Succeeds” service fails, is generalized to:
Create a TODO whenever MR became unmergeable
(and similar to notification, MR author and merge_user are both applicable)
|
| |\
| |
| |
| |
| | |
Save and expose only generic merge error
See merge request gitlab-org/gitlab-ce!18646
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When an error occurs during merge, the error message is exposed to user
and it is also saved in DB. This error message may be user unfriendly
(as in !41820) and it could also expose a detailed backend information.
Instead of displaying the specific error message, only sanitized generic
message is displayed. This is potentially controversial change because
disadvantage is that user doesn't get specific reason of failure.
Additional changes:
* repository.merge including exceptions is is extracted into a
separate method to make things clearer
* update! is used instead of update so we don't silently ignore
an error
Related to !41857
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The NotificationService has to do quite a lot of work to calculate the
recipients for an email. Where possible, we should try to avoid doing this in an
HTTP request, because the mail are sent by Sidekiq anyway, so there's no need to
schedule those emails immediately.
This commit creates a generic Sidekiq worker that uses Global ID to serialise
and deserialise its arguments, then forwards them to the NotificationService.
The NotificationService gains an `#async` method, so you can replace:
notification_service.new_issue(issue, current_user)
With:
notification_service.async.new_issue(issue, current_user)
And have everything else work as normal, except that calculating the recipients
will be done by Sidekiq, which will then schedule further Sidekiq jobs to send
each email.
|
| |
|
|
|
|
|
|
|
|
| |
So we can distinguish between the permissions on the source and the
target project.
- `create_merge_request_from` indicates a user can create a merge
request with the project as a source_project
- `create_merge_request_in` indicates a user can create a merge
request with the project as a target_project
|
| |
|
|
|
|
|
| |
This prevents creating merge requests targeting archived projects.
This could happen when a project was already forked, but then the
source was archived.
|
| |
|
|
| |
Closes #23460
|
| |
|
|
|
|
| |
Previously, we kept them all in the cache. We don't need the highlight results
for older diffs - if someone does view that (which is rare), we can do the
highlighting on the fly.
|
| |\
| |
| |
| |
| |
| |
| | |
Cache `#can_be_resolved_in_ui?` git operations
Closes gitaly#1051
See merge request gitlab-org/gitlab-ce!17589
|
