| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| | |
Refactor code around scheduling cluster installations
See merge request gitlab-org/gitlab-ce!19108
|
| |
| |
| |
| | |
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
| | |
|
| |
| |
| |
| | |
enabled
|
|\ \
| |/
|/|
| |
| |
| |
| |
| |
| | |
'master'
Fixed badge api endpoint route when relative_url is set
Closes #46411
See merge request gitlab-org/gitlab-ce!19004
|
| | |
|
|\ \
| | |
| | |
| | |
| | | |
[CE] Resolve "Extract EE specific files/lines for some controllers"
See merge request gitlab-org/gitlab-ce!18994
|
| |/
| |
| |
| |
| |
| | |
Projects::Settings::IntegrationsController
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |
| |
| |
| |
| |
| |
| |
| | |
When displaying a project's pipelines
(Projects::PipelinesController#index) we now exclude the coverage data.
This data was not used by the frontend, yet getting it would require one
SQL query per pipeline. These queries in turn could be quite expensive
on GitLab.com.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When displaying the pipelines of a project we now preload the following
data:
1. Authors of the commits that belong to these pipelines
2. The number of warnings per pipeline, which is used by
Ci::Pipeline#has_warnings?
== Commit Authors
Previously this data was queried for every Commit separately, leading to
20 SQL queries being executed in the worst case. With an average of 3 to
5 milliseconds per SQL query this could result in 100 milliseconds being
spent in _just_ getting Commit authors.
To preload this data Commit#author now uses BatchLoader (through
Commit#lazy_author), and a separate module
Gitlab::Ci::Pipeline::Preloader is used to ensure all authors are loaded
before they are used.
== Number of warnings
This changes Ci::Pipeline#has_warnings? so it supports preloading of the
number of warnings per pipeline. This removes the need for executing a
COUNT(*) query for every pipeline just to see if it has any warnings or
not.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When displaying the project pipelines dashboard we display a few tabs
for different pipeline states. For every such tab we count the number of
pipelines that belong to it. For large projects such as GitLab CE this
means having to count over 80 000 rows, which can easily take between 70
and 100 milliseconds per query.
To improve this we apply a technique we already use for search results:
we limit the number of rows to count. The current limit is 1000, which
means that if more than 1000 rows are present for a state we will show
"1000+" instead of the exact number. The SQL queries used for this
perform much better than a regular COUNT, even when a project has a lot
of pipelines.
Prior to these changes we would end up running a query like this:
SELECT COUNT(*)
FROM ci_pipelines
WHERE project_id = 13083
AND status IN ('success', 'failed', 'canceled')
This would produce a plan along the lines of the following:
Aggregate (cost=3147.55..3147.56 rows=1 width=8) (actual time=501.413..501.413 rows=1 loops=1)
Buffers: shared hit=17116 read=861 dirtied=2
-> Index Only Scan using index_ci_pipelines_on_project_id_and_ref_and_status_and_id on ci_pipelines (cost=0.56..2984.14 rows=65364 width=0) (actual time=0.095..490.263 rows=80388 loops=1)
Index Cond: (project_id = 13083)
Filter: ((status)::text = ANY ('{success,failed,canceled}'::text[]))
Rows Removed by Filter: 2894
Heap Fetches: 353
Buffers: shared hit=17116 read=861 dirtied=2
Planning time: 1.409 ms
Execution time: 501.519 ms
Using the LIMIT count technique we instead run the following query:
SELECT COUNT(*)
FROM (
SELECT 1
FROM ci_pipelines
WHERE project_id = 13083
AND status IN ('success', 'failed', 'canceled')
LIMIT 1001
) for_count
This query produces the following plan:
Aggregate (cost=58.77..58.78 rows=1 width=8) (actual time=1.726..1.727 rows=1 loops=1)
Buffers: shared hit=169 read=15
-> Limit (cost=0.56..46.25 rows=1001 width=4) (actual time=0.164..1.570 rows=1001 loops=1)
Buffers: shared hit=169 read=15
-> Index Only Scan using index_ci_pipelines_on_project_id_and_ref_and_status_and_id on ci_pipelines (cost=0.56..2984.14 rows=65364 width=4) (actual time=0.162..1.426 rows=1001 loops=1)
Index Cond: (project_id = 13083)
Filter: ((status)::text = ANY ('{success,failed,canceled}'::text[]))
Rows Removed by Filter: 9
Heap Fetches: 10
Buffers: shared hit=169 read=15
Planning time: 1.832 ms
Execution time: 1.821 ms
While this query still uses a Filter for the "status" field the number
of rows that it may end up filtering (at most 1001) is small enough that
an additional index does not appear to be necessary at this time.
See https://gitlab.com/gitlab-org/gitlab-ce/issues/43132#note_68659234
for more information.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Workhorse to send raw diff and patch for commits
Closes gitaly#1196
See merge request gitlab-org/gitlab-ce!18974
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Prior to this change, this was done through unicorn. In theory this
could time out. Workhorse has been sending these raw patches and diffs
for a long time and is stable in doing so.
Added bonus is the fact that `Commit#to_patch` can be removed.
`Commit#to_diff` too, which closes
https://gitlab.com/gitlab-org/gitaly/issues/324
Closes https://gitlab.com/gitlab-org/gitaly/issues/1196
|
| |/
|/| |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Remove Spinach
Closes #23036
See merge request gitlab-org/gitlab-ce!18869
|
| |/ |
|
|/ |
|
|\
| |
| |
| |
| | |
Fix failed jobs tab
See merge request gitlab-org/gitlab-ce!18520
|
| | |
|
|\ \
| | |
| | |
| | |
| | | |
Improve UX For Group Runners
See merge request gitlab-org/gitlab-ce!18649
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
These were just shorthands for project_... and they will be confusing when introducing group runners so we should not have them (#10244)
|
| | | |
|
| | | |
|
| | | |
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | | |
Resolve "CI retry/cancel job or pipeline redirect the user and can't be open in a new tab"
Closes #33697
See merge request gitlab-org/gitlab-ce!18451
|
| |\ \ |
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
* master: (48 commits)
Get rid of config/initializers/2_app.rb and define Gitlab in lib/gitlab.rb
Fix eslint
Fix eslint
Address latest feedback
Moved committer and spec. Added some extra code to run hooks or not depending on the options
Fix minor typos
Fix disabled state while making a request
Move Settings to its own file, isolate it from Rails and introduce Gitlab.root
Document the new 'spec/fast_spec_helper.rb' file
Introduce spec/fast_spec_helper.rb to run spec files that don't rely on the whole Rails env
Move spec helpers/matchers/shared examples/contexts to their relevant folder
Use axios request to interact with API instead of UJS
Emit `toggleCollapse`, `onDropdownClose` on component
Add changelog for 2fa filter in users api
Add 2FA filter to users API for admins only
Emit `onValueClick` event on component when container is clicked
Fix project creation for user endpoint bug
Update repository storages documentation URL
Flowdock uses Gitaly, not Grit
fix revoke header on deploy token docs
...
|
| | | | | |
|
| | | | | |
|
|\ \ \ \ \
| |_|_|_|/
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
'44059-specify-variables-when-executing-a-manual-pipeline-from-the-ui' into 'master'
Resolve "Specify variables when executing a manual pipeline from the UI"
Closes #44059
See merge request gitlab-org/gitlab-ce!18440
|
| |\ \ \ \
| | | |_|/
| | |/| |
| | | | | |
44059-specify-variables-when-executing-a-manual-pipeline-from-the-ui
|
| |\ \ \ \
| | | |_|/
| | |/| |
| | | | | |
44059-specify-variables-when-executing-a-manual-pipeline-from-the-ui
|
| | | | | |
|
| | | | | |
|
|\ \ \ \ \ |
|
| | |_|/ /
| |/| | | |
|
| |\ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
'blackst0ne-rails5-use-safe-params-instead-of-params-in-url-for-helpers' into 'master'
[Rails5] Use `safe_params` instead of `params` in `url_for` helpers
See merge request gitlab-org/gitlab-ce!18637
|
| | | |/ /
| | |/| |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This commits replaces `params` with `safe_params` in `url_for` helpers
to resolve security issues [1] and failing specs with the
```
ArgumentError:
Attempting to generate a URL from non-sanitized request parameters!
An attacker can inject malicious data into the generated URL, such as
changing the host. Whitelist and sanitize passed parameters to be secure.
```
error.
[1]: https://gitlab.com/gitlab-org/gitlab-ce/issues/45168
|
| |\ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Fix file_store for artifacts and lfs when saving
See merge request gitlab-org/gitlab-ce!18624
|
| | |/ / / |
|
| |/ / / |
|
| | | |
| | | |
| | | |
| | | | |
runner.belonging_to_parent_group_of_project(project.id)`
|
| | | |
| | | |
| | | |
| | | | |
ProjectSettings
|
| | | | |
|
| | | | |
|
| | | | |
|