| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Issue boards
## What are the relevant issue numbers?
- Issue: #17907
- Issue backend: #20335
- Backend MR: !5548
- Frontend MR: !5554
- Documentation !5713
## 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
- [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)
- [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
See merge request !5548
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Tracking of custom events
## What does this MR do?
This MR adds the ability to track custom events such as the number of Git pushes.
## Are there points in the code the reviewer needs to double check?
The usual stuff.
## Why was this MR needed?
We want to track more business level data such as the number of Git pushes, how many repositories are imported (and from where), etc.
## What are the relevant issue numbers?
gitlab-org/gitlab-ce#13720
## 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)
cc @pcarranza
See merge request !5830
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
GitLab Performance Monitoring is now able to track custom events not
directly related to application performance. These events include the
number of tags pushed, repositories created, builds registered, etc.
The use of these events is to get a better overview of how a GitLab
instance is used and how that may affect performance. For example, a
large number of Git pushes may have a negative impact on the underlying
storage engine.
Events are stored in the "events" measurement and are not prefixed with
"rails_" or "sidekiq_", this makes it easier to query events with the
same name triggered from different parts of the application. All events
being stored in the same measurement also makes it easier to downsample
data.
Currently the following events are tracked:
* Creating repositories
* Removing repositories
* Changing the default branch of a repository
* Pushing a new tag
* Removing an existing tag
* Pushing a commit (along with the branch being pushed to)
* Pushing a new branch
* Removing an existing branch
* Importing a repository (along with the URL we're importing)
* Forking a repository (along with the source/target path)
* CI builds registered (and when no build could be found)
* CI builds being updated
* Rails and Sidekiq exceptions
Fixes gitlab-org/gitlab-ce#13720
|
| |\ \
| | |
| | |
| | |
| | | |
# Conflicts:
# app/controllers/projects/merge_requests_controller.rb
|
| | |\ \
| | |/ |
|
| | |\ \ |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
An MR can only be resolved in the UI if:
- It has conflicts.
- It has valid diff_refs (in other words, it supports new diff notes).
- It has no conflicts with one side missing.
- It has no conflicts in binary files.
- It has no conflicts in files too large to display.
- It has no conflicts containing invalid conflict markers.
|
| | | | | |
|
| |\ \ \ \
| |_|_|/
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Resolve "Pipelines for merge request"
## What does this MR do?
Adds `Pipelines` tab in merge request view
## What are the relevant issue numbers?
Closes #18681
## Screenshots (if relevant)
See merge request !5485
|
| | |\ \ \
| | | | |
| | | | |
| | | | | |
18681-pipelines-merge-request
|
| | |\ \ \ \
| | | | | |
| | | | | |
| | | | | | |
18681-pipelines-merge-request
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Use just SQL to check is a user can admin_issue on a project
Tradeoff
- we duplicate how we check admin_issue in a SQL relation in the Ability class
|
| |\ \ \ \ \ \
| | |_|/ / /
| |/| | | |
| | | | | | |
pipeline-hooks-without-slack
|
| | | |/ / /
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
!581 has a lot of changes that would cause merge conflicts if not
properly backported to CE. This commit/MR serves as a better
foundation for gitlab-org/gitlab-ee!581.
= Changes =
1. Move from `has_one {merge,push}_access_level` to `has_many`, with the
`length` of the association limited to `1`. This is _effectively_ a
`has_one` association, but should cause less conflicts with EE, which
is set to `has_many`. This has a number of related changes in the
views, specs, and factories.
2. Make `gon` variable loading more consistent (with EE!581) in the
`ProtectedBranchesController`. Also use `::` to prefix the
`ProtectedBranches` services, because this is required in EE.
3. Extract a `ProtectedBranchAccess` concern from the two access level
models. This concern only has a single `humanize` method here, but
will have more methods in EE.
4. Add `form_errors` to the protected branches creation form. This is
not strictly required for EE compatibility, but was an oversight
nonetheless.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
- 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.
|
| | | | | |
|
| |\ \ \ \
| |/ / / |
|
| | |\ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Add method missing from EE
## Why was this MR needed?
`ProjectWiki#repository_exists?` is present in EE but not on CE, and there's no particular reason why it shouldn't
See merge request !5802
|
| | | | |/
| | |/| |
|
| | |\ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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
|
| | |\ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Try to get back todo's cache or at least avoid hitting the database
See merge request !5789
|
| | | | | | | |
|
| | | |/ / /
| |/| | | |
|
