- 05 6月, 2018 3 次提交
-
-
由 Bob Van Landuyt 提交于
When we want to show an access denied message to a user, we don't have to hide the resource's existence. So in that case we render a 403, this 403 is not handled by nginx on omnibus installs, making sure the message is visible to the user.
-
由 tauriedavis 提交于
We show a blue flash banner if the user already accepted, and show a button allowing them to continue to the application.
-
由 Jarka Kadlecová 提交于
-
- 04 6月, 2018 1 次提交
-
-
由 Bob Van Landuyt 提交于
Since we don't show the archived projects, we shouldnot load them and pass them to the fronted to be filtered out again.
-
- 01 6月, 2018 1 次提交
-
-
由 Francisco Javier López 提交于
-
- 31 5月, 2018 4 次提交
-
-
由 Imre Farkas 提交于
-
由 Kamil Trzciński 提交于
-
由 Dylan Griffith 提交于
-
由 Oswaldo Ferreira 提交于
-
- 29 5月, 2018 3 次提交
-
-
由 blackst0ne 提交于
-
由 Toon Claes 提交于
-
由 Bob Van Landuyt 提交于
This endpoint lists projects shared with a group visible to the current user. The `filter` and `sort` params are supported like on the `children` endpoint.
-
- 25 5月, 2018 9 次提交
-
-
由 Rémy Coutable 提交于
Signed-off-by: NRémy Coutable <remy@rymai.me>
-
由 Rémy Coutable 提交于
Signed-off-by: NRémy Coutable <remy@rymai.me>
-
由 Rémy Coutable 提交于
Signed-off-by: NRémy Coutable <remy@rymai.me>
-
由 Rémy Coutable 提交于
Signed-off-by: NRémy Coutable <remy@rymai.me>
-
由 Rémy Coutable 提交于
Signed-off-by: NRémy Coutable <remy@rymai.me>
-
由 Rémy Coutable 提交于
Signed-off-by: NRémy Coutable <remy@rymai.me>
-
由 Rémy Coutable 提交于
Signed-off-by: NRémy Coutable <remy@rymai.me>
-
由 Rémy Coutable 提交于
Signed-off-by: NRémy Coutable <remy@rymai.me>
-
由 Rémy Coutable 提交于
Signed-off-by: NRémy Coutable <remy@rymai.me>
-
- 23 5月, 2018 1 次提交
-
-
由 Tiago Botelho 提交于
-
- 17 5月, 2018 3 次提交
-
-
由 Yorick Peterse 提交于
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.
-
由 Yorick Peterse 提交于
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.
-
由 lulalala 提交于
First, transitions between can_be_merged & cannot_be_merged are removed, as they are currently blocked in `check_if_can_be_merged`. `can_be_merge` always returns to `unchecked` first, before it can transition to `cannot_be_merged` (and vice versa). We want to avoid repeated notification triggered by repeated transition between `cannot_be_merged` & `unchecked`. So we added `cannot_be_merged_recheck` state, similar to `unchecked`, but as a mean to remember it’s from cannot_be_merged. See https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18042/#note_65945407 Since `unchecked` and `cannot_be_merged_recheck` both mean “we are in the middle of checking if it is mergeable”, quite often we need to see if merge_status is in either one of them, so `check_state?` is added to achieve this.
-
- 16 5月, 2018 2 次提交
-
-
由 Zeger-Jan van de Weg 提交于
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
-
由 Dylan Griffith 提交于
-
- 14 5月, 2018 1 次提交
-
-
由 Stan Hu 提交于
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
-
- 11 5月, 2018 1 次提交
-
-
由 blackst0ne 提交于
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.
-
- 07 5月, 2018 4 次提交
-
-
由 Tiago Botelho 提交于
-
由 Marc 提交于
-
由 Tiago Botelho 提交于
Remove password and password_confirmation from whitelisted params in ProfilesController to prevent password from being changed without previous password being provided
-
由 Dylan Griffith 提交于
-
- 04 5月, 2018 4 次提交
-
-
由 Bob Van Landuyt 提交于
`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.
-
由 Bob Van Landuyt 提交于
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.
-
由 Bob Van Landuyt 提交于
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.
-
由 Bob Van Landuyt 提交于
When terms are present, they can be viewed on `/-/users/terms`.
-
- 03 5月, 2018 3 次提交
-
-
由 Winnie Hellmann 提交于
-
由 Matija Čupić 提交于
-
由 Matija Čupić 提交于
-