| Age | Commit message (Collapse) | Author |
|---|
|
Submit to Akismet Part 1 (Issues)
Related to #5932 #5573 gitlab-com/infrastructure#14
See merge request !5538
|
|
|
|
|
|
|
|
- Refactored SpamCheckService into SpamService
|
|
- Added controller actions as reusable concerns
- Added controller tests
|
|
- Added `submitted_as_ham` to `SpamLog` to mark which logs have been submitted to Akismet.
- Added routes and controller action.
|
|
- Removed unnecessary column from `SpamLog`
- Moved creation of SpamLogs out of its own service and into SpamCheckService
- Simplified code in SpamCheckService.
- Moved move spam related code into Spammable concern
|
|
- Merged `AkismetSubmittable` into `Spammable`
- Clean up `SpamCheckService`
- Added tests for `Spammable`
- Added submit (ham or spam) options to `AkismetHelper`
|
|
- New concern `AkismetSubmittable` to allow issues and other `Spammable` models to be submitted to Akismet.
- New model `UserAgentDetail` to store information needed for Akismet.
- Services needed for their creation and tests.
|
|
Show deployment status on a MR view
## What are the relevant issue numbers?
Resolves #19571, one in the list of #19992
## Screenshots (if relevant)
external_url = nil
external_url != nil
Note, the timings are weird between merging and deploying, that is because I did it in the wrong order.
## Does this MR meet the acceptance criteria?
- [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
See merge request !5622
|
|
Limit the size of SVGs when viewing them as blobs
## What does this MR do?
This MR prevents rendering of SVG blobs larger than 2 MB.
## Are there points in the code the reviewer needs to double check?
I couldn't figure out how to properly test the view for this as this requires a large SVG (inflating the repository size) _or_ stubbing, the latter doesn't really seem possible using Spinach and all the stuff potentially involved.
## Why was this MR needed?
When rendering large SVG blobs (e.g. 20 MB files) a request may time out and consume a lot of memory.
## What are the relevant issue numbers?
#1435
## 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] ~~[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
- [ ] 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)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
cc @jschatz1 @annabeldunstone (there are some UI changes, see the above screenshot).
See merge request !5794
|
|
This ensures that SVGs greater than 2 megabytes are not scrubbed and
rendered. This in turn prevents requests from timing out due to
reading/scrubbing large SVGs potentially taking a lot of time (and
memory). The use of 2 megabytes is completely arbitrary.
Fixes gitlab-org/gitlab-ce#1435
|
|
|
|
|
|
|
|
|
|
|
|
`reload_status!` call
|
|
|
|
|
|
|
|
|
|
Refactor pipeline creation service
## What does this MR do?
This refactors GitLab CI build processing: all builds for pipeline are pre-created when a pipeline object is created.
The builds are created with a new introduced status `created`.
The builds are then automatically promoted to `pending` when a previous stage do succeed.
This significantly simplifies pipeline processing code solving a lot of problems of lazily initialisation of previous approach (builds were created on-demand).
## Why was this MR needed?
The previous mechanism had a lot of flows (shown in related issues) in how it work, but also in code design. Removing cross model-service-library dependencies.
The current approach moves a build creation to single place `CreatePipelineService` and removes a dynamic dependency on `config_processor` significantly simplifying a build creation and pipeline processing. Pipeline processing is implemented in `ProcessPipelineService`.
This also allows to easily extend GitLab with Manual Actions which is part of 8.10 direction issue.
## Migration problem
~~This MR removes the a on-demand creation of builds in pipelines.
Pipelines that are running and are in mid-stage (some stages started, but not all) will not be fully evaluated after application restart.
This happens, because the code responsible for on-demand creation is removed.
There's no easy way to migrate existing pipelines, other than doing offline migration and putting pipeline processing in migration code (which seems to be a really bad idea).~~
To support old pipelines I added a lazy initialization of builds if none is found.
## What are the relevant issue numbers?
Fixes: https://gitlab.com/gitlab-org/gitlab-ce/issues/12839
Solves: https://gitlab.com/gitlab-org/gitlab-ce/issues/18644 https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/289
Allows to easily implement: https://gitlab.com/gitlab-org/gitlab-ce/issues/17010
## 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)
- [x] 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)
See merge request !5295
|
|
This change simplifies a Pipeline processing by introducing a special new status: created.
This status is used for all builds that are created for a pipeline.
We are then processing next stages and queueing some of the builds (created -> pending) or skipping them (created -> skipped).
This makes it possible to simplify and solve a few ordering problems with how previously builds were scheduled.
This also allows us to visualise a full pipeline (with created builds).
This also removes an after_touch used for updating a pipeline state parameters.
Right now in various places we explicitly call a reload_status! on pipeline to force it to be updated and saved.
|
|
'master'
Add group members API endpoints to request access and approve requests
## What does this MR do?
Add group members API endpoints to request access and approve requests.
## Are there points in the code the reviewer needs to double check?
I chose to factorize the group/project members API as well as the new group/project access requests API.
I initially also created new services to centralize the permission checks related to actions on members, but this was out of scope and this MR is already quite big so I opened a temp MR at !5566 based on this one.
## Why was this MR needed?
To finish the "request access" feature.
## What are the relevant issue numbers?
Closes #18583.
## 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
- [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 !4833
|
|
Replace the tinder gem by bare HTTP requests
## What does this MR do?
It removes the `tinder` gem (used to talk to the Campfire API) and replaces its use by bare HTTP requests.
## Are there points in the code the reviewer needs to double check?
N/A.
## Why was this MR needed?
To simplify the potential dependency hell discussed in #13333.
The initial issue was about updating `http_parser.rb` which was required by `twitter-stream` which was required by `tinder`.
Those 3 gems are not needed anymore.
## What are the relevant issue numbers?
#13333
## Screenshots (if relevant)
N/A.
## 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)
- 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 #13333
See merge request !5758
|
|
|
|
Also, mutualize AccessRequests and Members endpoints for Group &
Project.
New API documentation for the AccessRequests endpoints.
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
Instead of redirecting from the project service to the service and back to the model,
put all destruction code in the service. Also removes a possible source of failure
where run_after_commit may not destroy the project.
|
|
This is in preparation to address the DB load caused by the counting in
gitlab-com/infrastructure#303.
|
|
|
|
Optimize "cache_key" using a concern
## What does this MR do?
This MR adds a concern (used by Issue and Note) that provides an optimized version of Rails' `cache_key` method. See 77c8520e2ecd70520757aed0fbdf434643b60234 for more details.
## Are there points in the code the reviewer needs to double check?
No, though a spell check would be appreciated.
## Why was this MR needed?
When loading a lot of data from Redis (e.g. an issue with lots of notes) quite a large amount of time is spent in generating cache keys. This is due to multiple reasons such as:
* Rails trying to figure out if it should use `updated_at` or `updated_on` using somewhat inefficient code
* Rails relying on pluralization logic to figure out how to generate a cache namespace using a model name
* Rails calling a whole bunch of methods in general in the process of generating cache keys
In short, Rails is trying to cater to every possible use case, at the cost of performance.
## What are the relevant issue numbers?
https://gitlab.com/gitlab-org/gitlab-ce/issues/13651 is not directly related but I ran into this `cache_key` problem when looking into said issue.
See merge request !5715
|
|
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.
|
|
'14898-protected-branches-developer-can-not-push-without-permission' into 'master'
Developer cannot push to protected branch when project is empty or he has not been granted permission to do so
This MR was created following !1979 and !1978
Closes #14898
See merge request !1980
|
|
aswell
|
|
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.
|
|
|
|
|
|
So we have raw_diffs too
|
|
Instead calling diff_collection.count use diff_collection.size which is cache on the diff_collection
|
|
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
|
|
|
|
not been granted permission to do so
|
|
|
|
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
|
