| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This concern provides an optimized/simplified version of the "cache_key"
method. This method is about 9 times faster than the default "cache_key"
method.
The produced cache keys _are_ different from the previous ones but this
is worth the performance improvement. To showcase this I set up a
benchmark (using benchmark-ips) that compares FasterCacheKeys#cache_key
with the regular cache_key. The output of this benchmark was:
Calculating -------------------------------------
cache_key 4.825k i/100ms
cache_key_fast 21.723k i/100ms
-------------------------------------------------
cache_key 59.422k (± 7.2%) i/s - 299.150k
cache_key_fast 543.243k (± 9.2%) i/s - 2.694M
Comparison:
cache_key_fast: 543243.4 i/s
cache_key: 59422.0 i/s - 9.14x slower
To see the impact on real code I applied these changes and benchmarked
Issue#referenced_merge_requests. For an issue referencing 10 merge
requests these changes shaved off between 40 and 60 milliseconds.
|
| |
|
|
|
|
| |
This will avoid lame conflicts when merging CE to EE
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
'20512-fix-rename-add-users-into-project-to-add-users-to-project-and-projects-ids-to-project-ids' into 'master'
Fix Rename `add_users_into_project` and `projects_ids`
## What does this MR do?
Only modifies the name of a method that leaves more semantic and expressive and the name of the keywords arguments to the rails convention.
## Are there points in the code the reviewer needs to double check?
Only if it has been changed at every point that is calling this method and that passing arguments.
## Why was this MR needed?
To make the code more expressive.
## What are the relevant issue numbers?
Closes #20512.
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- Tests
- [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 !5659
|
| | |
| |
| |
| |
| |
| | |
We never add things `into` projects, we just add them `to` projects. So how about we rename this to `add_users_to_project`.
Rename `projects_ids` to `project_ids` by following the convention of rails.
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fix Import/Export not working in HA mode
Use a shared path instead of `Tempfile` default `/tmp` so the import file is accessible by any GitLab instance.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/20506
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- Tests
- [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 !5618
|
| | |
| |
| |
| | |
export worker
|
| | | |
|
| | |
| |
| |
| | |
avatar to save memory
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
So we have raw_diffs too
|
| | |
| |
| | |
This object will manage Gitlab::Git::Compare instances
|
| | |
| |
| | |
Instead calling diff_collection.count use diff_collection.size which is cache on the diff_collection
|
| | |
| |
| |
| | |
Introducing the concept of SafeDiffs which relates
diffs with UI highlighting.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Add simple identifier to public SSH keys
## What does this MR do?
Adds a simple identifier of user_name + hostname to public SSH keys
## Are there points in the code the reviewer needs to double check?
## Why was this MR needed?
To help people identify keys when they export them
## What are the relevant issue numbers?
#18866
## Screenshots (if relevant)
## 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
- [ x] 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)
Closes #18866
See merge request !5614
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
touching git repository to return diff_refs when possible
- 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.
|
| |\ \ \
| |_|/
|/| |
| | |
| | | |
Only use RequestStore in ProjectTeam#max_member_access_for_users if it is active
See merge request !5604
|
| | |/ |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fix attr reader to force the intended values for source and target shas
## What does this MR do?
When importing a pull request from GitHub, the old and new branches may no longer actually exist by those names, but we need to recreate the merge
request diff with the right source and target shas. We use these `target_branch_sha` and `source_branch_sha` attributes to force these to the intended values. But the reader methods were always looking up to the target/source branch head instead of check if these values was previously set, this MR applies a memoization pattern to both of them.
## Are there points in the code the reviewer needs to double check?
This [commit](https://gitlab.com/gitlab-org/gitlab-ce/commit/6ce25e7b4caa9e94de74378729178c7060d640b2) introduced this bug in the importer.
## What are the relevant issue numbers?
gitlab-org/gitlab-ce#20385
## Does this MR meet the acceptance criteria?
- [X] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [X] ~~[Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)~~
- [X] ~~API support added~~
- Tests
- [X] Added for this feature/bug
- [ ] All builds are passing
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
/cc @akitaonrails @DouweM
See merge request !5573
|
| | | | |
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When importing a pull request from GitHub, the old and new branches may
no longer actually exist by those names, but we need to recreate the
merge request diff with the right source and target shas.
We use these `target_branch_sha` and `source_branch_sha` attributes to
force these to the intended values. But the reader methods were always
looking up to the target/source branch head instead of check if these
values was previously set.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fix Importing labels and milestones associations - Import/Export
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/19510 and https://gitlab.com/gitlab-org/gitlab-ce/issues/19447
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- Tests
- [x] 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 !5426
|
| | |/
| |
| |
| | |
refactored reader class a bit
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add an URL field to Enviroments
## What does this MR do?
Adds a field to the `enviroments` table to expose later in other features. Now I see the task list below, I noticed I forgot some minor things, but Ill adress those after the first review.
## Are there points in the code the reviewer needs to double check?
The field is a string on the database, thus limited to 255 chars, which seems more than enough.
## What are the relevant issue numbers?
Closes #19527
## Screenshots (if relevant)
## Does this MR meet the acceptance criteria?
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [x] API support added
- Tests
- [x] 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] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
See merge request !5469
|
| | | |
|
| | |
| |
| |
| |
| | |
This MR adds a string (thus max 255 chars) field to the enviroments
table to expose it later in other features.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Optimize checking if a user can read multiple issues
## What does this MR do?
This optimizes various parts of the code so it can more efficiently check if a user can read a list of issues.
## Are there points in the code the reviewer needs to double check?
Yes, in particular `Ability.issues_readable_by_user` should be checked to make sure it correctly allows/restricts access to issues.
## Why was this MR needed?
Currently the general approach to checking if one can read an issue is to iterate over the issues to check and call `can?(user, :read_issue, issue)` for every issue. This is not efficient as the same work has to be done for every issue.
## What are the relevant issue numbers?
* #15607
* #17463
See merge request !5370
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The method Ability.issues_readable_by_user takes a list of users and an
optional user and returns an Array of issues readable by said user. This
method in turn is used by
Banzai::ReferenceParser::IssueParser#nodes_visible_to_user so this
method no longer needs to get all the available abilities just to check
if a user has the "read_issue" ability.
To test this I benchmarked an issue with 222 comments on my development
environment. Using these changes the time spent in nodes_visible_to_user
was reduced from around 120 ms to around 40 ms.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Enable Rubocop cops that check access modifiers
## What does this MR do?
This MR enables Rubocop cops that detect methods that should be restricted but are the part of public API because of access modifiers used improperly.
This also fixes existing offenses.
## Why was this MR needed?
Some method in our codebase are public instead of being private because it is sometimes difficult to get it right without static analysis.
## What are the relevant issue numbers?
See #17478
Closes #17372
See merge request !5014
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This enables following cops:
Check for useless access modifiers
Lint/UselessAccessModifier
Checks for attempts to use `private` or `protected` to set the
visibility of a class method, which does not work.
Lint/IneffectiveAccessModifier
This also disables two false possitives in concerns.
|
| | | | | |
|
| | |_|/
|/| | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1. Instantiate `ProtectedBranchesAccessSelect` from `dispatcher`
2. Use `can?(user, ...)` instead of `user.can?(...)`
3. Add `DOWNTIME` notes to all migrations added in !5081.
4. Add an explicit `down` method for migrations removing the
`developers_can_push` and `developers_can_merge` columns, ensuring that
the columns created (on rollback) have the appropriate defaults.
5. Remove duplicate CHANGELOG entries.
6. Blank lines after guard clauses.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1. It makes sense to reuse these constants since we had them duplicated
in the previous enum implementation. This also simplifies our
`check_access` implementation, because we can use
`project.team.max_member_access` directly.
2. Use `accepts_nested_attributes_for` to create push/merge access
levels. This was a bit fiddly to set up, but this simplifies our code
by quite a large amount. We can even get rid of
`ProtectedBranches::BaseService`.
3. Move API handling back into the API (previously in
`ProtectedBranches::BaseService#translate_api_params`.
4. The protected branch services now return a `ProtectedBranch` rather
than `true/false`.
5. Run `load_protected_branches` on-demand in the `create` action, to
prevent it being called unneccessarily.
6. "Masters" is pre-selected as the default option for "Allowed to Push"
and "Allowed to Merge".
7. These changes were based on a review from @rymai in !5081.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1. Remove `master_or_greater?` and `developer_or_greater?` in favor of
`max_member_access`, which is a lot nicer.
2. Remove a number of instances of `include Gitlab::Database::MigrationHelpers`
in migrations that don't need this module. Also remove comments where
not necessary.
3. Remove duplicate entry in CHANGELOG.
4. Move `ProtectedBranchAccessSelect` from Coffeescript to ES6.
5. Split the `set_access_levels!` method in two - one each for `merge` and
`push` access levels.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
1. In the context of protected branches.
2. Test this behaviour.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
1. The model now contains this humanization data, which is the once
source of truth.
2. Previously, this was being listed out in the dropdown component as well.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1. Remove `Project#developers_can_push_to_protected_branch?` since it
isn't used anymore.
2. Remove `Project#developers_can_merge_to_protected_branch?` since it
isn't used anymore.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1. Reuse the same dropdown component that we used for updating these
settings (`ProtectedBranchesAccessSelect`). Have it accept options
for the parent container (so we can control the elements it sees) and
whether or not to save changes via AJAX (we need this for update, but
not create).
2. Change the "Developers" option to "Developers + Masters", which is
clearer.
3. Remove `developers_can_push` and `developers_can_merge` from the
model, since they're not needed anymore.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1. The crux of this change is in `UserAccess`, which looks through all
the access levels, asking each if the user has access to push/merge
for the current project.
2. Update the `protected_branches` factory to create access levels as
necessary.
3. Fix and augment `user_access` and `git_access` specs.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1. Move to dropdowns instead of checkboxes. One each for "Allowed to
Push" and "Allowed to Merge"
2. Refactor the `ProtectedBranches` coffeescript class into
`ProtectedBranchesAccessSelect`.
3. Modify the backend to accept the new parameters.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1. Improve error handling while creating protected branches.
2. Modify coffeescript code so that the "Developers can *" checkboxes
send a '1' or '0' even when using AJAX. This lets us keep the backend
code simpler.
3. Use services for both creating and updating protected branches.
Destruction is taken care of with `dependent: :destroy`
|
| | |/
|/|
| |
| | |
- And hook up their associations.
|
| |\ \
| | |
| | |
| | |
| | | |
Cache the commit author in RequestStore to avoid extra lookups in PostReceive
See merge request !5537
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In a PostReceive task with 697 commits (8.9 RC1 -> RC8), looking up
the commit author takes about 10% of the time. Caching this information
in RequestStore saves a few seconds from the overall processing time.
Improves #18663
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
'17073-tagscontroller-index-is-terrible-response-time-goes-up-to-5-seconds' into 'master'
Update to gitlab_git 10.4.1 and take advantage of preserved Ref objects
See merge request !5536
|
| | | | | |
|
