- 16 Aug, 2017 1 commit
-
-
Bob Van Landuyt authored
`failure_count_threshold`: We should never need this, but we don't want to block access in tests because of this. `failure_wait_time`: Setting it to 0 now allows each storage attempt `storage_timeout`: Try a bit longer to access storage on CI in case the slow machines take a bit longer to spin up the process to perfom the check
-
- 07 Aug, 2017 1 commit
-
-
Paweł Chojnacki authored
-
- 04 Aug, 2017 1 commit
-
-
Bob Van Landuyt authored
-
- 31 Jul, 2017 1 commit
-
-
Michael Kozono authored
-
- 26 Jul, 2017 4 commits
-
-
Michael Kozono authored
-
Michael Kozono authored
-
Michael Kozono authored
-
Michael Kozono authored
-
- 17 Jul, 2017 1 commit
-
-
Alexandros Keramidas authored
-
- 07 Jul, 2017 2 commits
-
-
Jacob Vosmaer authored
-
Timothy Andrew authored
- The `migration:path-pg` build was previously failing when the Authentiq feature spec was enabled by placing Authentiq configuration in the `test` section of `gitlab.yml` - The `migration:path-pg` task checks out an old revision of the codebase (`v8.14.10`) and runs a `schema:load`. It then checks out the commit under test, and runs `db:migrate`, to verify that migrations run without errors. - The problem here is that `v8.14.10` does not have the Authentiq module installed, but is run with the `gitlab.yml` for `master`, which would contain the `Authentiq` configuration in the `test` section. - The solution was to use the `v8.14.10` `gitlab.yml` for the `schema:load`, rather than the `gitlab.yml` from master.
-
- 06 Jul, 2017 6 commits
-
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
Rémy Coutable authored
A `performance_team` Flipper group has been created. By default this group is nil but this can be customized in `gitlab.yml` via the performance_bar.allowed_group setting. Signed-off-by: Rémy Coutable <remy@rymai.me>
-
Timothy Andrew authored
- This is causing autoload-related errors in the `migration:path` builds. We need to find a better way of testing this provider.
-
Timothy Andrew authored
- Don't use `request.env['omniauth.params']` if it isn't present. - Remove the `saml` section from the `gitlab.yml` test section. Some tests depend on this section not being initially present, so it can be overridden in the test. This MR doesn't add any tests for SAML, so we didn't really need this in the first place anyway. - Clean up the test -> omniauth section of `gitlab.yml`
-
Timothy Andrew authored
- I tried to get this to work by stubbing out portions of the config within the test. This didn't work as expected because Devise/Omniauth loaded before the stub could run, and the stubbed config was ignored. - I attempted to fix this by reloading Devise/Omniauth after stubbing the config. This successfully got Devise to load the stubbed providers, but failed while trying to access a route such as `user_gitlab_omniauth_authorize_path`. - I spent a while trying to figure this out (even trying `Rails.application.reload_routes!`), but nothing seemed to work. - I settled for adding this config directly to `gitlab.yml` rather than go down this path any further.
-
- 05 Jul, 2017 1 commit
-
-
Sean McGivern authored
This reverts merge request !11963
-
- 04 Jul, 2017 4 commits
-
-
Pawel Chojnacki authored
-
Pawel Chojnacki authored
-
Pawel Chojnacki authored
in favor of whitelist that will be used to control the access to monitoring resources
-
Paweł Chojnacki authored
-
- 03 Jul, 2017 2 commits
-
-
Timothy Andrew authored
- Don't use `request.env['omniauth.params']` if it isn't present. - Remove the `saml` section from the `gitlab.yml` test section. Some tests depend on this section not being initially present, so it can be overridden in the test. This MR doesn't add any tests for SAML, so we didn't really need this in the first place anyway. - Clean up the test -> omniauth section of `gitlab.yml`
-
Timothy Andrew authored
- I tried to get this to work by stubbing out portions of the config within the test. This didn't work as expected because Devise/Omniauth loaded before the stub could run, and the stubbed config was ignored. - I attempted to fix this by reloading Devise/Omniauth after stubbing the config. This successfully got Devise to load the stubbed providers, but failed while trying to access a route such as `user_gitlab_omniauth_authorize_path`. - I spent a while trying to figure this out (even trying `Rails.application.reload_routes!`), but nothing seemed to work. - I settled for adding this config directly to `gitlab.yml` rather than go down this path any further.
-
- 20 Jun, 2017 2 commits
-
-
Jacob Vosmaer authored
-
Jacob Vosmaer authored
-
- 19 Jun, 2017 1 commit
-
-
Jacob Vosmaer authored
-
- 07 Jun, 2017 1 commit
-
-
Robin Bobbitt authored
-
- 02 Jun, 2017 2 commits
-
-
Pawel Chojnacki authored
-
Pawel Chojnacki authored
-
- 01 Jun, 2017 1 commit
-
-
Douwe Maan authored
-
- 30 May, 2017 1 commit
-
-
Jacob Vosmaer authored
-
- 22 May, 2017 1 commit
-
-
Z.J. van de Weg authored
-
- 07 May, 2017 1 commit
-
-
Zeger-Jan van de Weg authored
-
- 27 Apr, 2017 1 commit
-
-
Chris Wilson authored
GitLab uses the import_project method in GitLab Shell, This method uses a timeout for the operation, hardcoded to 800 seconds. With this MR the timeout is now configurable in the gitlab_shell settings.
-
- 19 Apr, 2017 1 commit
-
-
Jakub Jirutka authored
Hard-coding location of configuration files is very bad practice. This patch applies the same approach as currently used for gitlab_shell_secret file.
-
- 11 Apr, 2017 1 commit
-
-
Alejandro Rodríguez authored
-
- 06 Apr, 2017 3 commits
-
-
Shinya Maeda authored
-
Shinya Maeda authored
-
Shinya Maeda authored
-