- Preloading noteable we share the same noteable instance when more than one
discussion refers to the same noteable.
- Any other call to that object that is cached in that object will be for any
discussion.
- In those cases where merge_request_diff has all the sha stored to build a diff_refs get that
diff_refs using directly those sha instead accessing to the git repository to first get the
commits and later the sha.
Provide more sensible default sort order for issues and merge requests
based on the following table:
| type | state | default sort order |
|----------------|--------|--------------------|
| issues | open | last created |
| issues | closed | last updated |
| issues | all | last created |
| merge requests | open | last created |
| merge requests | merged | last updated |
| merge requests | closed | last updated |
| merge requests | all | last created |
NotesHelper#note_editable? and ProjectTeam#human_max_access currently
take about 16% of the load time of an issue page. This MR preloads
the maximum access level of users for all notes in issues and merge
requests with several queries instead of one per user and caches
the result in RequestStore.
Avoid calculation of closes_issues.
## What does this MR do?
Avoid unneeded calls to MR closes issues
## Are there points in the code the reviewer needs to double check?
I'm not sure if calling this method from a view is a good practice, but I cannot see another simple way of avoiding this problem. In case we want to avoid this in the controller we need to specify the action, format and status of the merge request, because in that case we know that the `_open` partial will render. We could add some lazy evaluation but it not a thing I see in use along the app but feedback is welcome
## What are the relevant issue numbers?
#14202 , #19490
## Does this MR meet the acceptance criteria?
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- ~~[ ] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)~~
- ~~[ ] API support added~~
- Tests
- ~~[ ] Added for this feature/bug~~
- [x] All builds are passing
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
See merge request !5140
1. Move render method to a concern, not a helper.
2. Let DiffHelper#diff_options automatically add the path option.
3. Move more instance var definitions to before filters.
The issue was that `MergeRequest#mergeable?` returns false when the CI
state is not success and project.only_allow_merge_if_build_succeeds is
true. In this case `Projects::MergeRequestsController#merge` would
return the `:failed` status when enabling `merge_when_build_succeeds`,
thus leading to a weird state and the MR never automatically merged.
The fix is to disable the CI state check in the controller safeguard
that early return the `:failed` status.
Signed-off-by: Rémy Coutable <remy@rymai.me>
This commit changes the way certain documents are rendered (currently
only Notes) and how documents are redacted. Previously both rendering
and redacting would run on a per document basis. The result of this was
that for every document we'd have to run countless queries just to
figure out if we could display a set of links or not.
This commit changes things around so that redacting Markdown documents
is no longer tied into the html-pipeline Gem. This in turn allows it to
redact multiple documents in a single pass, thus reducing the number of
queries needed.
In turn rendering issue/merge request notes has been adjusted to take
advantage of this new setup. Instead of rendering Markdown somewhere
deep down in a view the Markdown is rendered and redacted in the
controller (taking the current user and all that into account). This has
been done in such a way that the "markdown()" helper method can still be
used on its own.
This particular commit also paves the way for caching rendered HTML on
object level. Right now there's an accessor method Note#note_html which
is used for setting/getting the rendered HTML. Once we cache HTML on row
level we can simply change this field to be a column and call a "save"
whenever needed and we're pretty much done.
* commit 'ca3c5c295ed653b483fe81c3918ffe60f46666b9':
Let contributors know where to start
Ensure branch cleanup regardless of whether the import process succeeds
Fix failing todo tests
Reorder the todos because the use of the project finder attempts to order them differently
Update target todo test to use a public project
Use the project finder in the todos finder to limit todos to just ones within projects you have access to.
Move filtering todos by projects not pending deletion into a scope on the todo model
Reduce the filters on the todos joins project query by being explicit about the join
Ensure we don't show TODOS for projects pending delete
Fix deprecation warnings in spec/services/issues/bulk_update_service_spec.rb
Remove unused Issuable#is_assigned? method
fixup! Don't allow merges with new commits
fixup! Add `sha` parameter to MR accept API
Reduce Namespace queries in UserReferenceFilter
Added ReferenceFilter#nodes
Returning enums in ReferenceFilter#each_node
Don't allow merges with new commits
Add `sha` parameter to MR accept API
Set a `sha` parameter on the MR form. If this doesn't match the HEAD of
the source branch when the form is submitted, show a warning (like with
a merge conflict) and don't merge the branch.
Fixes text color on labels in sidebar
Previously the labels in the sidebar would just have `#FFF` text color which could cause problems with a light background color.
With this, the text color comes from the JSON.
See merge request !3846
Ci::Commit becomes a Pipeline object
1. Ci::Commit receives context: ref, :tag.
1. One Ci::Commit describes a one Pipeline
1. Pipeline is created from `.gitlab-ci.yml`
1. Pipeline is a ordered group of builds
1. We test MR against Pipeline
1. Pipelines have a separate view (https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3703)
1. Pipeline can be triggered from UI (https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3703)
1. Later we change `Trigger -> TriggerRequest -> Build` to `Trigger -> Pipeline` (future)
1. We add a Pipeline Hook that will be triggered on Pipeline status change (future)
1. We extend notifications to use `Pipeline Hook` to send summary on pipeline changes (future)
After merging that I'll prepare a separate MR that will unify naming, database columns, table names:
```
Ci::Commit -> Pipeline
Ci::Build -> Build
CommitStatus -> Job
GenericCommitStatus -> ExternalJob
ci_commits -> pipelines
ci_builds -> jobs
```
This MR implements first 5 points.
This is made to solve this issue https://gitlab.com/gitlab-org/gitlab-ce/issues/14149.
See merge request !3653
Fix Raw / Rendered diff producing different results on merge requests
The raw diff endpoint (`merge_requests/####.diff`) produces a diff based on `target_branch` instead of the original branching point. Same is valid for `merge_requests/####.patch`.
Fixes#14680, #3017
See merge request !3450
1. Make the "subscribed" text in Issuable sidebar reflect the labels
subscription status
2. Current user mut be logged-in to toggle issue/MR/label subscription
Ci Project migrate
- This doesn't migrate: allow_git_fetch, coverage_regex, timeout. Since this are project configuration settings I would propose to migrate them to `.gitlab-ci.yml`.
- This requires offline migrations.
- It simplifies database models making all CI objects to be attached to: Project.
- It removes Ci::Project, but makes /ci/projects working by adding method: Project.find_by_ci_id for backward compatibility (badges, triggers).
- We should add default `timeout` to Application Settings.
- It misses specs.
- It is based on ci-services-migrate for now.
- It removes CI events.
- It removes administrator CI projects overview.
- It removes CI application settings.
In 8.4 or 8.5 we can remove redundant tables and columns.
See merge request !1987
write_ was renamed to create_
modify_ was renamed to update_
So now in update action we have next code
def create
can?(current_user, :create_issue, @issue)
end
def update
can?(current_user, :update_issue, @issue)
end
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
* store @participants in variable
* store result of subscribed? call into variable
In total it reduce amount of SQL queries for merge_request with 10
comments/participants twice.
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
It is same search like we have at issues page. It allows to quickly
filter merge requests based on title or desription. I copy-pasted some
js code from Issues.js. In future search (filtering) logic should be
refactoed into one class for merge requests and issues
Make the Markdown parser recognize "[x]" or "[ ]" at the beginning of a
list item and turn it into a checkbox input. Users who can modify the
issue or MR can toggle the checkboxes directly or edit the Markdown to
manage the tasks. Task status is also displayed in the MR and issue
lists.
* fix 500 error when no parent for initial commit
* fix link from diff files to wrong commit
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
Merge request target branch select is broken if you submit form and have
some errors on page
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
Previously, only number of changed files mattered. Now, number of lines to render in the diff are also taken into account.
A hard limit is set, above which diffs are not rendered and users are not allowed to override that. This prevents high server
resource usage with huge commits.
Related to #1745, #2259
In addition, handle large commits for MergeRequests and Compare controllers.
Also fixes a bug where diffs are loaded twice, if user goes directly to merge_requests/:id/diffs URL.
Any mention of Issues, MergeRequests, or Commits via GitLab-flavored markdown
references in descriptions, titles, or attached Notes creates a back-reference
Note that links to the original referencer. Furthermore, pushing commits with
commit messages that match a (configurable) regexp to a project's default
branch will close any issues mentioned by GFM in the matched closing phrase.
If accepting a merge request would close any Issues in this way, a banner is
appended to the merge request's main panel to indicate this.
-Form was for @source_project rather then @project.
-add spinach test for edit submission on forked project
Change-Id: I807a5077608b7e910f4bc83c5d3e82c378f70a9e
-update new to be simplified (set values from parms via rails) instead of doing it by hand
-change def merge_request to look up the merge request against the current @project
Change-Id: I778c91b87c6da84b73f8f59013c27b74d290d8b1
-Some changes around calling origional methods for !for_fork? merge requests. Other changes to follow
Change-Id: I009c716ce2475b9efa3fd07aee9215fca7a1c150
-Disable observers post test run
-Allow db:seed_fu RAILS_ENV=test to be run more than once without error
-fix diffs_in_between, was passing in the default_options for grit, but grit in this case doesn't take options, fixed the test to actually fail if the incorrect diffs are returned
-make notes/commits render against proper project
-MR discussion file links should reference note's project
-Added tests for commit links on edit merge request
-fixes edit issues (canceling an edited mr, updating an edited mr)
-updates tests with checks for source code updates
-still forked_merge_requests.feature (project_forked_merge_requests) test not passing (commented out -- "stable" not being set)
MR API: error on bad target_project
-If the target project id is specified and it is not the same as the project the request is being made on (the source), and the it isn't a fork of that project, error out, otherwise use it as the target
-Fixes some busted (but hidden) test cases
Conflicts:
app/views/merge_requests/show/_diffs.html.haml
spec/features/notes_on_merge_requests_spec.rb
Change-Id: I20e595c156d0e8a63048baaead7be6330c738a05
The good:
- You can do a merge request for a forked commit and it will merge properly (i.e. it does work).
- Push events take into account merge requests on forked projects
- Tests around merge_actions now present, spinach, and other rspec tests
- Satellites now clean themselves up rather then recreate
The questionable:
- Events only know about target projects
- Project's merge requests only hold on to MR's where they are the target
- All operations performed in the satellite
The bad:
- Duplication between project's repositories and satellites (e.g. commits_between)
(for reference: http://feedback.gitlab.com/forums/176466-general/suggestions/3456722-merge-requests-between-projects-repos)
Fixes:
Make test repos/satellites only create when needed
-Spinach/Rspec now only initialize test directory, and setup stubs (things that are relatively cheap)
-project_with_code, source_project_with_code, and target_project_with_code now create/destroy their repos individually
-fixed remote removal
-How to merge renders properly
-Update emails to show project/branches
-Edit MR doesn't set target branch
-Fix some failures on editing/creating merge requests, added a test
-Added back a test around merge request observer
-Clean up project_transfer_spec, Remove duplicate enable/disable observers
-Ensure satellite lock files are cleaned up, Attempted to add some testing around these as well
-Signifant speed ups for tests
-Update formatting ordering in notes_on_merge_requests
-Remove wiki schema update
Fixes for search/search results
-Search results was using by_project for a list of projects, updated this to use in_projects
-updated search results to reference the correct (target) project
-udpated search results to print both sides of the merge request
Change-Id: I19407990a0950945cc95d62089cbcc6262dab1a8