| Age | Commit message (Collapse) | Author |
|---|
|
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 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
|
|
|
|
If you upload a file with a .js extension, Rails' cross-origin JavaScript
protection will prevent a user from downloading the file with a 422 error.
Setting the content-type to `text/plain` will allow the user to download
the file as a plaintext file.
Closes #45826
|
|
In Rails 5.0 `response.content_type` does not return charset which is expected in specs.
This commit replaces `response.content_type` with `response.headers["Content-Type"]` in specs.
|
|
Improve UX For Group Runners
See merge request gitlab-org/gitlab-ce!18649
|
|
CE backport of Backports Push Mirrors to CE
Closes #42099
See merge request gitlab-org/gitlab-ce!18715
|
|
New CI Job live-trace architecture (v2)
Closes #44935
See merge request gitlab-org/gitlab-ce!18169
|
|
|
|
|
|
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
|
|
|
|
|
|
`InternalRedirect` prevents Open redirect issues by only allowing
redirection to paths on the same host.
It cleans up any unwanted strings from the path that could point to
another host (fe. //about.gitlab.com/hello). While preserving the
querystring and fragment of the uri.
It is already used by:
- `TermsController`
- `ContinueParams`
- `ImportsController`
- `ForksController`
- `SessionsController`: Only for verifying the host in CE. EE allows
redirecting to a different instance using Geo.
|
|
This enforces the terms in the web application. These cases are
specced:
- Logging in: When terms are enforced, and a user logs in that has not
accepted the terms, they are presented with the screen. They get
directed to their customized root path afterwards.
- Signing up: After signing up, the first screen the user is presented
with the screen to accept the terms. After they accept they are
directed to the dashboard.
- While a session is active:
- For a GET: The user will be directed to the terms page first,
after they accept the terms, they will be directed to the page
they were going to
- For any other request: They are directed to the terms, after they
accept the terms, they are directed back to the page they came
from to retry the request. Any information entered would be
persisted in localstorage and available on the page.
|
|
When a user accepts, we store this in the agreements to keep track of
which terms they accepted. We also update the flag on the user.
|
|
When terms are present, they can be viewed on `/-/users/terms`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Legacy disk path refactor
Closes gitaly#1111
See merge request gitlab-org/gitlab-ce!18364
|
|
Direct disk access is done through Gitaly now, so the legacy path was
deprecated. This path was used in Gitlab::Shell however. This required
the refactoring in this commit.
Added is the removal of direct path access on the project model, as that
lookup wasn't needed anymore is most cases.
Closes https://gitlab.com/gitlab-org/gitaly/issues/1111
|
|
Refactor OmniauthCallbacksController to remove duplication
Closes #26559
See merge request gitlab-org/gitlab-ce!16694
|
|
|
|
|
|
|
|
|
|
|
|
Moves LDAP to its own controller with tests
Provides path forward for implementing GroupSaml
|
|
'No job log' message is no longer necessary since we returned an image
when a build does not have a trace. See
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18278 for more
details
Closes #45625
|
|
|
|
Fix specifying a non-default ref when requesting an archive using the legacy URL
Closes #45507
See merge request gitlab-org/gitlab-ce!18468
|
|
|
|
|
|
|
|
There are 2 problems with this spec:
1. It checks for default visiblity level however there is not code in
controller to handle such default. Same check can be performed on model
directly.
2. It passes empty application_setting hash while controller requires
application_setting not to be empty by using `require` with `permit`
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
|
|
This could only be possible for users that can create merge requests
within a project.
So they need to be a allowed to create a branch and create a merge request.
|
|
|
|
The legacy endpoint requires no reference and defaults to the root
ref.
Closes #45154
|
