- 26 Jan, 2018 1 commit
-
-
Lin Jen-Shin authored
TODO: fix offenders
-
- 24 Jan, 2018 3 commits
-
-
Nick Thomas authored
-
Nick Thomas authored
-
James Edwards-Jones authored
-
- 22 Jan, 2018 1 commit
-
-
Alejandro Rodríguez authored
-
- 19 Jan, 2018 1 commit
-
-
Alejandro Rodríguez authored
-
- 18 Jan, 2018 1 commit
-
-
Rémy Coutable authored
Signed-off-by: Rémy Coutable <remy@rymai.me>
-
- 17 Jan, 2018 4 commits
-
-
Mario de la Ossa authored
Adds `#build_notification_recipients` to `NotificationRecipientService` that returns the `NotificationRecipient` objects in order to be able to access the new attribute `reason`. This new attribute is used in the different notifier methods in order to add the reason as a header: `X-GitLab-NotificationReason`. Only the reason with the most priority gets sent.
-
Robert Speicher authored
[10.3] Prevent login with disabled OAuth providers See merge request gitlab/gitlabhq!2296 (cherry picked from commit 4936650427ffc88e6ee927aedbb2c724d24b094c) a0f9d222 Prevents login with disabled OAuth providers
-
Sean McGivern authored
check project access on MR create See merge request gitlab/gitlabhq!2273 (cherry picked from commit 1fe2325d6ef2bced4c5e97b57691c894f38b2834) 43e85f49 check project access on MR create
-
Stan Hu authored
Merge branch 'security-10-3-do-not-expose-passwords-or-tokens-in-service-integrations-api' into 'security-10-3' Filter out sensitive fields from the project services API See merge request gitlab/gitlabhq!2281 (cherry picked from commit 476f2576444632f2a9a61b4cead9c1077f2c81d7) 2bcbbda0 Filter out sensitive fields from the project services API
-
- 15 Jan, 2018 1 commit
-
-
Jacob Vosmaer authored
-
- 11 Jan, 2018 2 commits
-
-
🙈 jacopo beschi 🙉 authored
-
Matija Čupić authored
-
- 05 Jan, 2018 3 commits
-
-
Brent Greeff authored
-
Jarka Kadlecová authored
-
Jacob Vosmaer (GitLab) authored
-
- 04 Jan, 2018 3 commits
-
-
Felipe Artur authored
-
Jose Ivan Vargas authored
-
Mayra Cabrera authored
-
- 03 Jan, 2018 1 commit
-
-
Douglas Barbosa Alexandre authored
-
- 22 Dec, 2017 3 commits
-
-
Mayra Cabrera authored
-
Stan Hu authored
According to the Chrome source code (https://chromium.googlesource.com/chromium/src/base/+/master/base_switches.cc#120): The /dev/shm partition is too small in certain VM environments, causing Chrome to fail or crash (see http://crbug.com/715363). Use this flag to work-around this issue (a temporary directory will always be used to create anonymous shared memory files). Addresses gitlab-org/gitlab-ee#4252 but doesn't appear to cure it completely.
-
blackst0ne authored
-
- 21 Dec, 2017 2 commits
-
-
Matija Čupić authored
-
Matija Čupić authored
-
- 19 Dec, 2017 1 commit
-
-
Robert Speicher authored
Previously, this would include the entire User record in the update hash, which was rendered in the response using `to_json`, erroneously exposing every attribute of that record, including their (now removed) private token. Now we only include the user ID, and perform the lookup on-demand.
-
- 16 Dec, 2017 1 commit
-
-
Matija Čupić authored
-
- 15 Dec, 2017 1 commit
-
-
Sean McGivern authored
The ApplicationSetting model uses the CacheMarkdownField concern, which updates the cached HTML when the field is updated in the database. However, in specs, when we want to test conditions using ApplicationSetting, we stub it, because this is accessed in different ways throughout the application. This means that if a spec runs that caches one of the Markdown fields, and a later spec uses `stub_application_setting` to set the raw value of that field, the cached value was still the original one. We can work around this by ignoring the Markdown cache in contexts where we're using `stub_application_setting`. We could be smarter, and only do this on the Markdown fields of the model, but this is probably fine.
-
- 14 Dec, 2017 3 commits
-
-
Nick Thomas authored
By importing this Ruby code into gitlab-rails (and gitaly-ruby), we avoid 200ms of startup time for each gitlab_projects subprocess we are eliminating. By not having a gitlab_projects subprocess between gitlab-rails / sidekiq and any git subprocesses (e.g. for fork_project, fetch_remote, etc, calls), we can also manage these git processes more cleanly, and avoid sending SIGKILL to them
-
Rémy Coutable authored
I've followed the [upgrade guide](https://github.com/thoughtbot/factory_bot/blob/4-9-0-stable/UPGRADE_FROM_FACTORY_GIRL.md) and ran these two commands: ``` grep -e FactoryGirl **/*.rake **/*.rb -s -l | xargs sed -i "" "s|FactoryGirl|FactoryBot|" grep -e factory_girl **/*.rake **/*.rb -s -l | xargs sed -i "" "s|factory_girl|factory_bot|" ``` Signed-off-by: Rémy Coutable <remy@rymai.me>
-
Douwe Maan authored
-
- 08 Dec, 2017 1 commit
-
-
Bob Van Landuyt authored
Moving the check out of the general requests, makes sure we don't have any slowdown in the regular requests. To keep the process performing this checks small, the check is still performed inside a unicorn. But that is called from a process running on the same server. Because the checks are now done outside normal request, we can have a simpler failure strategy: The check is now performed in the background every `circuitbreaker_check_interval`. Failures are logged in redis. The failures are reset when the check succeeds. Per check we will try `circuitbreaker_access_retries` times within `circuitbreaker_storage_timeout` seconds. When the number of failures exceeds `circuitbreaker_failure_count_threshold`, we will block access to the storage. After `failure_reset_time` of no checks, we will clear the stored failures. This could happen when the process that performs the checks is not running.
-
- 07 Dec, 2017 1 commit
-
-
Jarka Kadlecova authored
-
- 06 Dec, 2017 3 commits
-
-
Takuya Noguchi authored
-
Michael Kozono authored
Later migrations added fields to the EE DB which were used by factories which were used in these specs. And in CE on MySQL, a single appearance row is enforced. The migration and migration specs should not depend on the codebase staying the same.
-
Yorick Peterse authored
This throttles the number of UPDATE queries that can be triggered by calling "touch" on a Note, Issue, or MergeRequest. For Note objects we also take care of updating the associated "noteable" relation in a smarter way than Rails does by default.
-
- 04 Dec, 2017 1 commit
-
-
Bob Van Landuyt authored
-
- 03 Dec, 2017 1 commit
-
-
Zeger-Jan van de Weg authored
-
- 01 Dec, 2017 1 commit
-
-
Michael Kozono authored
* Hopefully fixes spec failures in which the table doesn’t exist * Decouples the background migration from the post-deploy migration, e.g. we could easily run it again even though the table is dropped when finished.
-