An error occurred fetching the project authors.
- 27 Jul, 2021 1 commit
-
-
Yorick Peterse authored
This module contained various methods that were forwarded to Gitlab::Database::Connection. This commit removes these wrappers in favour of using Gitlab::Database.main instead. This is done to make it explicit what database connection should be used. See https://gitlab.com/gitlab-org/gitlab/-/issues/331776 and https://gitlab.com/gitlab-org/gitlab/-/merge_requests/65262 for more information.
-
- 14 Apr, 2021 1 commit
-
-
Sean McGivern authored
This feature flag was there to test a fix to feature flag caching logic, and it seems to have fixed the issue so we can remove the flag.
-
- 01 Apr, 2021 1 commit
-
-
Sean McGivern authored
On GitLab.com we sometimes observe that a feature flag has been changed - and we have the response in chatops to demonstrate that - but the behaviour of the application doesn't reflect that. While we cannot prove that this is the case, we believe that this is due to a combination of these factors: 1. We have some feature flags (Gitaly feature flags in particular) that are read very frequently. All Gitaly feature flags are read on every Gitaly call. 2. We use database load balancing, so a read from a secondary may be slightly behind the primary. 3. The feature flag library we use (Flipper) deletes the feature flag from the cache when it's changed, and relies on the next read to re-populate the cache. As these reads use what is essentially `Rails.cache.fetch`, the last writer 'wins'. That could lead to this situation: 1. Client A is using the primary. It performs `fetch`, finds nothing, executes its block to get the value. 2. Client B does the same, but using a secondary and missing out the write performed by client A. 3. Client A finishes its block and writes to Redis. 4. Client B does the same, clobbering client A's write. The solution in this change is simple: instead of deleting the feature flag from the cache when updating it, we always immediately write the new value back. That way any clients using `Rails.cache.fetch` won't attempt to write until the cache has expired after an hour, by which point the secondaries would have caught up anyway. This is behind a feature flag because it is a somewhat risky change, but using a feature flag is safe here as this only controls how we handle feature flag writes.
-
- 29 Mar, 2021 1 commit
-
-
Vitali Tatarintev authored
This reverts merge request !56746
-
- 26 Mar, 2021 1 commit
-
-
Vitali Tatarintev authored
Add missing definition files for some feature flags
-
- 10 Mar, 2021 1 commit
-
-
Vitali Tatarintev authored
Removes `type: :licensed` from feature flags
-
- 14 Dec, 2020 1 commit
-
-
Fabio Pitino authored
When `default_enabled: :yaml` is passed to the Feature.enabled? method we read the value from the YAML definition. With this change we can use the YAML definition as a SSOT. Changing the default behavior would simply mean flipping the `default_enabled` in the YAML file, rather than at every occurrence in the code.
-
- 02 Dec, 2020 1 commit
-
-
Shinya Maeda authored
This commit improves the logging
-
- 21 Sep, 2020 1 commit
-
-
Kamil Trzciński authored
This does: - add all leftover `development` feature flags - ensures that licensed `feature flags` are actually checked against `type: :licensed` - makes `development` to be `optional: false`, aka `required`
-
- 30 Jun, 2020 1 commit
-
-
Kamil Trzciński authored
This adds a YAML-based definition of feature flags that are stored in `(ee/)configs/feature-flags/`. Currently none of feature flag types are required to have a present YAML definition. This definition contains information like: - what MR introduced FF - helps to create and has a issue that tracks the rollout and removal of FF - intentionally adds `default_enabled` to YAML - force checks the consistency of `default_enabled` between what is in code and what is in YAML
-
- 29 Jun, 2020 1 commit
-
-
Kamil Trzciński authored
The new method of fetching feature flags seems to behave correctly. This is safe to remove the feature flag.
-
- 23 Jun, 2020 1 commit
-
-
Arturo Herrero authored
The plan for RSpec 4.0 is to disable monkey patching, reference: https://rspec.info/blog/2013/07/the-plan-for-rspec-3/#zero-monkey-patching-mode https://relishapp.com/rspec/rspec-core/docs/configuration/zero-monkey-patching-mode This commit stops using RSpec monkey patching in several specs.
-
- 01 Jun, 2020 1 commit
-
-
Kamil Trzciński authored
This removes the usage of `Feature.get` and instead provides a helpers for almost all possible usages.
-
- 29 May, 2020 1 commit
-
-
Kamil Trzciński authored
This makes us to use a memoized Flipper engine that simply always works. We also change a implementation of `persisted_names` to use a `Flipper` instead of requesting features manually. By default a memoized engine is used, which can be overwritten with `stub_feature_flags: false`. The memoized engine requires us to use object that are `FeatureGate-inherited`. We ensure that this holds true, always. This MR also updates all tests to adhere to this requirement.
-
- 06 May, 2020 1 commit
-
-
Heinrich Lee Yu authored
Thread-local cache is ineffective when using Puma because unused threads are reaped until it reaches the min threads setting. We already tested this ProcessMemoryCache for feature flags so this enables it for other classes where we're still using ThreadMemoryCache
-
- 18 Mar, 2020 1 commit
-
-
Stan Hu authored
When we switched from a single-threaded application server (Unicorn) to a multithreaded one (Puma), we did not realize that Puma often reaps threads after a request is done and recreates them later. This makes the thread-local cache ineffective, as the cache does not store anything beyond the lifetime of the thread. Since `ActiveSupport::Cache::MemoryStore` is thread-safe, we should be able to switch the L1 cache for the feature flag list to use this to reduce load on Redis. Since read and write access is synchronized, this does have the side effect of adding contention when feature flags are accessed. We made a similar change in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/26935, and this seems to be working fine. Discovered in https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/9414
-
- 11 Mar, 2020 1 commit
-
-
Stan Hu authored
When we switched from a single-threaded application server (Unicorn) to a multithreaded one (Puma), we did not realize that Puma often reaps threads after a request is done and recreates them later. This makes the thread-local cache ineffective, as the cache does not store anything beyond the lifetime of the thread. Since `ActiveSupport::Cache::MemoryStore` is thread-safe, we should be able to switch the L1 cache for feature flags to use this to reduce load on Redis. Since read and write access is synchronized, this does have the side effect of adding contention when feature flags are accessed. Discovered in https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/9414
-
- 10 Jan, 2020 1 commit
-
-
Bob Van Landuyt authored
Before calling out to the database to check if a feature is enabled or not, first check if the database exists. This allows us to use feature checks during the setup of the application.
-
- 02 Dec, 2019 1 commit
-
-
Heinrich Lee Yu authored
This reverts merge request !19759
-
- 29 Nov, 2019 1 commit
-
-
Balakumar authored
-
- 17 Oct, 2019 2 commits
-
-
Alex Buijs authored
- redirect users to almost there page after signing up when soft_email_confirmation is not enabled - remove enabled_since code for feature flags, since it is unreliable - add User#role_required? and User#set_role_required! methods to ‘abuse’ the role column in order to determine whether the role is required - store the requested url and redirect there after setting the role - add flash notice after successful signup - enable invisible captcha when signup_flow experiment is enabled - change `Welcome to GitLab.com` text to `Welcome to GitLab` in order to apply to Self hosted instances as well - cancel the signup_notice flash in the create action, where it is set
-
Alex Buijs authored
Only redirect to stage 2 of the new signup flow when appropriate: - a user’s role is missing - a user’s name is the same as it’s username - the experiment is enabled - the user is created after the experiment is enabled
-
- 31 Jul, 2019 1 commit
-
-
Ash McKenzie authored
-
- 26 Jul, 2019 1 commit
-
-
Thong Kuah authored
Using the sed script from https://gitlab.com/gitlab-org/gitlab-ce/issues/59758
-
- 03 Jul, 2019 1 commit
-
-
Stan Hu authored
In https://gitlab.com/gitlab-com/gl-infra/production/issues/928, we saw a significant amount of network traffic and CPU usage due to Redis checking feature flags via Flipper. Since these flags are hit with every request, the overhead becomes significant. To alleviate Redis overhead, we now cache the data in the following way: * L1: A thread-local memory store for 1 minute * L2: Redis for 1 hour
-
- 02 Jul, 2019 2 commits
-
-
Stan Hu authored
Now that application settings are no longer dominating network traffic, we see that the Feature#persisted_names is using a significant amount of CPU and network bandwidth for Redis. Move this cache into the thread-local memory storage to reduce Redis overhead.
-
Stan Hu authored
Now that application settings are no longer dominating network traffic, we see that the Feature#persisted_names is using a significant amount of CPU and network bandwidth for Redis. Move this cache into the thread-local memory storage to reduce Redis overhead.
-
- 18 Jun, 2019 1 commit
-
-
Stan Hu authored
We saw on GitLab.com, the SQL query, `SELECT "features"."key" FROM "features"` peaked at 2300 times per second. We can quiet this down a bit by caching it in Redis for a minute. Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/63435
-
- 19 Feb, 2019 1 commit
-
-
James Edwards-Jones authored
Building on support for setting feature flags by project, this adds support for setting them by GitLab group path. This is different from setting them by Flipper feature_groups, which are for batch updating pre-registered collections.
-
- 14 Jan, 2019 1 commit
-
-
Zeger-Jan van de Weg authored
For features the feature gates are sometimes projects, not groups or users. For example for git object pools: https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/5872 This commit allows for setting feature group gates based on projects, by its path as that seems most convenient.
-
- 24 Sep, 2018 1 commit
-
-
Michael Kozono authored
* Fix typo in context 'when request store is active' * Rearrange test since the instance variable always gets set now, even if RequestStore is active
-
- 05 Sep, 2018 1 commit
-
-
Brett Walker authored
This allows you to default a feature flag to 'on' when checking whether it's enabled/disabled.
-
- 22 Aug, 2018 1 commit
-
-
Gabriel Mazetto authored
Previous code would not work with `disabled?` because that method would send two parameters (second always `nil`) which we are not mocking. Instead of mock yet another state, I decide to fix it where it belongs.
-
- 20 Jul, 2018 1 commit
-
-
Douglas Barbosa Alexandre authored
-
- 01 Jun, 2018 1 commit
-
-
Rémy Coutable authored
Signed-off-by:
Rémy Coutable <remy@rymai.me>
-
- 08 Nov, 2017 1 commit
-
-
Yorick Peterse authored
The GitHub importer (and probably other parts of our code) ends up calling Feature.persisted? many times (via Gitaly). By storing this data in RequestStore we can save ourselves _a lot_ of database queries. Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/39361
-
- 07 Nov, 2017 1 commit
-
-
Yorick Peterse authored
The GitHub importer (and probably other parts of our code) ends up calling Feature.persisted? many times (via Gitaly). By storing this data in RequestStore we can save ourselves _a lot_ of database queries. Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/39361
-
- 27 Jul, 2017 1 commit
-
-
Rémy Coutable authored
Remove superfluous lib: true, type: redis, service: true, models: true, services: true, no_db: true, api: true Signed-off-by:
Rémy Coutable <remy@rymai.me>
-
- 26 Jul, 2017 1 commit
-
-
Rémy Coutable authored
Signed-off-by:
Rémy Coutable <remy@rymai.me>
-
- 21 Jun, 2017 1 commit
-
-
Grzegorz Bizon authored
-