| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Enables frozen for the following:
* lib/*.rb
* lib/banzai/**/*.rb
* lib/bitbucket/**/*.rb
* lib/constraints/**/*.rb
* lib/container_registry/**/*.rb
* lib/declarative_policy/**/*.rb
Partially addresses #47424.
|
| | |
|
| |
|
|
|
|
| |
* Fix typo in context 'when request store is active'
* Rearrange test since the instance variable always gets set now,
even if RequestStore is active
|
| |
|
|
| |
These are clear wins.
|
| | |
|
| |
|
|
|
| |
This allows you to default a feature flag to 'on' when
checking whether it's enabled/disabled.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our friends at GitHub show the programming languages for a long time,
and inspired by that this commit means to create about the same
functionality.
Language detection is done through Linguist, as before, where the
difference is that we cache the result in the database. Also, Gitaly can
incrementaly scan a repository. This is done through a shell out, which
creates overhead of about 3s each run. For now this won't be improved.
Scans are triggered by pushed to the default branch, usually `master`.
However, one exception to this rule the charts page. If we're requesting
this expensive data anyway, we just cache it in the database.
Edge cases where there is no repository, or its empty are caught in the
Repository model. This makes use of Redis caching, which is probably
already loaded.
The added model is called RepositoryLanguage, which will make it harder
if/when GitLab supports multiple repositories per project. However, for
now I think this shouldn't be a concern. Also, Language could be
confused with the i18n languages and felt like the current name was
suiteable too.
Design of the Project#Show page is done with help from @dimitrieh. This
change is not visible to the end user unless detections are done.
|
| | |
|
| |
|
|
|
|
| |
cleared between requests
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |
|
|
|
|
|
| |
Also, don't use the provided Middleware, which isn't thread-safe, and
instantiate a new Flipper instance per thread instead.
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |
|
|
|
|
|
|
| |
- Added an ActiveSupport (using Rails.cache) caching adapter
- Overview of the new features can be found at https://johnnunemaker.com/flippin-features-at-runtime/
- Full Changelog can be found at https://github.com/jnunemaker/flipper/blob/v0.11.0/Changelog.md
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
This is a follow-up for !12362 where this was documented but the code
was removed in the last iteration. Since this can still be useful and
this is already supported by the API, I think re-adding the code was
the best course of action.
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |
|
|
|
|
|
|
| |
This allows to enable/disable a feature flag for a given user, or a
given Flipper group (must be declared statically in the `flipper.rb`
initializer beforehand).
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This ensures we make maximum one call per feature per request.
See
https://github.com/jnunemaker/flipper/blob/v0.10.2/docs/Optimization.md#memoizing-middleware
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |
|
|
|
|
| |
This is controlled with the feature flag gitlab_git_diff_size_limit_increase.
Both of these limits were basically picked arbitrarily in the first place;
disabling the feature flag reverts to the old limits.
|
| |
|
