Created new emojis map in public folder
Renamed folder to emojis
Loading now the emojis from Localstorage or from Server
Moved all emojis to the public folder
Loading the emojis.json file now through AJAX
Loads now the map in the web element instead when building the emoji tag
Updated the custom Element Setup to modern method
Fixed Emoji Karma Specs for async loading
Loading now the emojis from Localstorage or from Server
Loads now the map in the web element instead when building the emoji tag
Fixed problem with FIXTURE_PATH for emojis fixtures
Fixes Linting Error in gemojione.rake
Fixed Emoji Karma Specs
Fix static type check in gemojione and check if already registered
Testing if the Emoji Support Check is failing Rspec
Change of CLass Name, returning true on check to test
Fixes failing Emoji RSpec Tests
Moved Emojis into public/-/emojis/1/
Fixed Linting Errors in gl_emoji
Fix to fixtures creation for emojis
Fixed path spec for new subdirectory -/emojis
Optimized emojis.json output
Fix for Emoji Spec failure due to unicode dataset
Better catch handling for emojis
This commit includes changes to add `UserAccess#can_create_branch?`
which will check whether the user is allowed to create a branch even
if it matches a protected branch.
This is used in `Gitlab::Checks::BranchCheck` when the branch name
matches a protected branch.
A `push_to_create_protected_branch` ability in `ProjectPolicy` has been
added to allow Developers and above to create protected branches.
Sidekiq jobs frequently spawn long-lived child processes to do work.
In some circumstances, these can be reparented to init when sidekiq is
terminated, leading to duplication of work and strange concurrency
problems.
This commit changes sidekiq so that, if run as a process group leader,
it will forward `INT` and `TERM` signals to the whole process group. If
the memory killer is active, it will also use the process group when
resorting to `kill -9` to shut down.
These changes mean that a naive `kill <pid-of-sidekiq>` will now do the
right thing, killing any child processes spawned by sidekiq, as long as
the process supervisor placed it in its own process group.
If sidekiq isn't a process group leader, this new code is skipped.
We've previously exposed ca_file and ssl_version but there are many
possible options that can be used inside tls_options. Instead of
exposing individual ones, simply expose the entire hash so it can
be passed in and we won't have to add things in the future.
In 11.8, we added a fix for the SearchFilesByContent RPC in gitaly to
send back the response in chunks. However, we kept in the old code path
for backwards compatibility. Now that the change is fully deployed, we
can remove that old codepath.
This brings back some of the changes in
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20339.
For users using Gitaly on top of NFS, accessing the Git data directly
via Rugged is more performant than Gitaly. This merge request introduces
the feature flag `rugged_find_commit` to activate Rugged paths.
There are also Rake tasks `gitlab:features:enable_rugged` and
`gitlab:features:disable_rugged` to enable/disable these feature
flags altogether.
Part of four Rugged changes identified in
https://gitlab.com/gitlab-org/gitlab-ce/issues/57317.
This change introduces a support for nesting the includes,
allowing to evaluate them in context of the target,
by properly respecting the relative inclusions and user permissions
of another projects, or templates.
Rollback is done similar to Migration for the Hashed Storage.
It also shares the same ExclusiveLease key to prevent both happening
at the same time.
All Hashed Storage related workers now share the same queue namespace
which allows for assigning dedicated workers easily.
We are adding sidekiq workers and service classes to allow to rollback
a hashed storage migration. There are some refactoring involved as well
as part of the code can be reused by both the migration and the rollback
logic.