The initializers including this were doing so at the top level, so every object
loaded after them had a `current_application_settings` method. However, if
someone had rack-attack enabled (which was loaded before these initializers), it
would try to load the API, and fail, because `Gitlab::CurrentSettings` didn't
have that method.
To fix this:
1. Don't include `Gitlab::CurrentSettings` at the top level. We do not need
`Object.new.current_application_settings` to work.
2. Make `Gitlab::CurrentSettings` explicitly `extend self`, as we already use it
like that in several places.
3. Change the initializers to use that new form.
* master: (275 commits)
Decrease Metrics/PerceivedComplexity threshold to 17
Upgrade mail and nokogiri gems due to security issues
Link out to stackoverflow answer on setting swappiness
Document swappiness recomendations in the requirements doc
Fix invalid attribute used for time-ago-tooltip component
Update latest artifacts doc
Add changelog entry for flipping verify_certificates
Default LDAP config verify_certificates to true
Update share project with groups docs
remove accidental console.log from karma tests
update specs to match reorganized monitoring components
Remove tooltips from new sidebar
Use `git update-ref --stdin -z` to delete refs
Don't use public_send in destroy_conditionally! helper
Remove unused expressions policy from ci/cd config
Simplify code for appending strategies in CI/CD config
Raise exception when simplifiable ci entry incomplete
Add changelog entry
Fix MySQL failure for emoji autocomplete
max-width for lazy-loaded images (this was removed in the original MR through merge resolution most probably)
...
Conflicts:
lib/gitlab/ci/config/entry/policy.rb
`allowed_key_types` is removed and the `minimum_<type>_bits` fields are
renamed to `<tech>_key_restriction`. A special sentinel value (`-1`) signifies
that the key type is disabled.
This also feeds through to the UI - checkboxes per key type are out, inline
selection of "forbidden" and "allowed" (i.e., no restrictions) are in.
As with the previous model, unknown key types are disallowed, even if the
underlying ssh daemon happens to support them. The defaults have also been
changed from the lowest known bit size to "no restriction". So if someone
does happen to have a 768-bit RSA key, it will continue to work on upgrade, at
least until the administrator restricts them.
This is an amalgamation of:
* Cory Hinshaw: Initial implementation !5552
* Rémy Coutable: Updates !9350
* Nick Thomas: Resolve conflicts and add ED25519 support !13712
* upstream/master: (225 commits)
Add changelog entry
Backports EE 2756 logic to CE.
Make rubocop happy
Make profile settings dropdown consistent
Add filter by my reaction
Update spec initialization with it being a shared component
Update identicon path and selector
Renamed to `identicon` and make shared component
Merge branch 'master-i18n' into 'master'
Fix broken Frontend JS guide
Replace 'project/star.feature' spinach test with an rspec analog
Adds position fixed to right sidebar
Fixes the margin of the top buttons of the pipeline page
Remove commented out code
Better align fallback image emojis
Decrease Metrics/CyclomaticComplexity threshold to 15
Add changelog
Respect the default visibility level when creating a group
Further break with_repo_branch_commit into parts
Make sure inspect doesn't generate crazy string
...
This adds a bunch of checks to migrations that may create or drop
triggers. Dropping triggers/functions is done using "IF EXISTS" so we
don't throw an error if the object in question has already been dropped.
We now also raise a custom error (message) when the user does not have
TRIGGER privileges. This should prevent the schema from entering an
inconsistent state while also providing the user with enough information
on how to solve the problem.
The recommendation of using SUPERUSER permissions is a bit extreme but
we require this anyway (Omnibus also configures users with this
permission).
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/36633
The change in !11728 would cause an arbitrary project to be chosen to test
system hooks, and it's likely that the project would not have any commits or
relevant commits to test the hook. This would prevent admins from verifying
that the hook fired. Instead of trying to create a representative hook
dynamically, just send static data to guarantee the hook will actually be
tested.
Closes#37067
For some old merge requests, we don't have enough information to figure out the
old blob and the new blob for the file. This means that we can't highlight the
diff correctly, but we can still display it without highlighting.
Users of project mirrors would see that the number of branches did not
match the number in the branch dropdown because remote branches were
counted when Rugged was in use. With Gitaly, only local branches
are counted.
Closes#36934
- Allow imports into nested groups
- Make sure it sets the correct visibility level when creating new
groups
While doing this, I moved the import into a testable class, that made
it easier to improve.
If this method was called for a file that didn't exist, we attempted to
first `build` it. But if the file wasn't writeable, such as a symlink
pointing to an unmounted filesystem, the method would just hang and
eventually timeout.
Further, this was entirely pointless since we were creating a file and
then shelling out to `tail`, eventually returning an empty Array. Now we
just skip building it and return the empty Array straight away.
* master: (115 commits)
Use event-based waiting in Gitlab::JobWaiter
Make sure repository's removal work for legacy and hashed storages
Use `@hashed` prefix for hashed paths on disk, to avoid collision with existing ones
Refactor project and storage types
Prevent using gitlab import task when hashed storage is enabled
Some codestyle changes and fixes for GitLab pages
Removed some useless code, codestyle changes and removed an index
Fix repository reloading in some specs
Changelog
Moving away from the "extend" based factory to a more traditional one.
Enable automatic hashed storage for new projects by application settings
New storage is now "Hashed" instead of "UUID"
Add UUID Storage to Project
Move create_repository back to project model as we can use disk_path and share it
Codestyle: move hooks to the same place and move dependent methods to private
Use non-i18n values for setting new group-level issue/MR button text
indexes external issue tracker
copyedit
indexes user/search/ from /user/index
Correctly encode string params for Gitaly's TreeEntries RPC
...
This gem allows Sidekiq jobs to be throttled. Unfortunately, it has a
side-effect: when we haven't enabled job throttling, it will still hit Redis a
lot (and miss, because nothing is configured).
As this setting already required a restart, ensure that the library is only
required when it's enabled.
Due to a missing `on_delete: :cascade`, users would hit the error that
looked like:
```
PG::ForeignKeyViolation: ERROR: update or delete on table "protected_tags"
violates foreign key constraint "fk_rails_f7dfda8c51" on table
"protected_tag_create_access_levels" DETAIL: Key (id)=(1385) is still
referenced from table "protected_tag_create_access_levels". : DELETE FROM
"protected_tags" WHERE "protected_tags"."id" = 1385
```
Closes#36013
- Adds a new `ProjectMovedError` class to encapsulate that error
condition. Inherits from `NotFoundError` so existing rescues should
continue to work.
- Separating that condition out of `NotFoundError` allowed us to
simplify the `raise_not_found` helper and avoid repeating the literal
string.
- Spec makes use of `ERROR_MESSAGES` hash to avoid repeating literal
error message strings.
Guess the modes based on the following:
1. If the file didn't exist, it's zero.
2. If the diff contains 'Subproject commit', it might be a submodule, so 0600.
3. Otherwise, it's 0644.
This isn't perfect, but it doesn't have to be - it won't change file modes in
the repository.
* master: (1000 commits)
Fix username autocomplete group name with no avatar alignment
Fix 'Projected tags' typo in protected_tags_spec.rb
Many Repo Fixes
Repo Editor Fixes
Docs: New index for permissions
link article from CI index
link tech articles from the landing page
new articles come first
fix relative link
fix date format
Fixed changed files dropdown not being shown
Update publication date
Remove deprecated field from workhorse API responses
Fix API responses when dealing with txt files
Make sure MySQL would not use CURRENT_TIMESTAMP
Add two more project templates
Allow usage of any_projects? with an Array
Copyedit Artifactory and GitLab article
Rename Artifactory and GitLab article file
Display GPG status loading spinner only when Ajax request is made
...
The `Rails` object was not always available in all tasks that require
Redis access, such as `mail_room`, so the constant pointing to the
configuration path was never defined, but we still attempted to access
it in `config_file_name`, resulting in a `NameError` exception.
Further, there was no benefit to defining these paths in a constant to
begin with -- they're only accessed in one place, and it was within the
class where they were being defined. We can just provide them at
run-time instead.
Further _still_, we were calling `File.expand_path` on the absolute path
returned by `Rails.root.join`, which was rather pointless.
Related to !13108. Mostly this is just running the rake task and
changing the task a bit to catch cases like the project already existing
or so. The rake task moves archives to the vendor/project_template
directory, which are checked in too.
setting of the gpg home directory is not thread safe, as the directoy
gets stored on the class.
if multiple threads change the directory at the same time, one of the
threads will be working in the wrong directory.
This changes various controllers to use the new EventCollection class
for retrieving events. This class uses a JOIN LATERAL query on
PostgreSQL to retrieve queries in a more efficient way, while falling
back to a simpler / less efficient query for MySQL.
The EventCollection class also includes a limit on the number of events
to display to prevent malicious users from cycling through all events,
as doing so could put a lot of pressure on the database.
JOIN LATERAL is only supported on PostgreSQL starting with version 9.3.0
and as such this optimisation is only used when using PostgreSQL 9.3 or
newer.
This commit migrates events data in such a way that push events are
stored much more efficiently. This is done by creating a shadow table
called "events_for_migration", and a table called "push_event_payloads"
which is used for storing push data of push events. The background
migration in this commit will copy events from the "events" table into
the "events_for_migration" table, push events in will also have a row
created in "push_event_payloads".
This approach allows us to reclaim space in the next release by simply
swapping the "events" and "events_for_migration" tables, then dropping
the old events (now "events_for_migration") table.
The new table structure is also optimised for storage space, and does
not include the unused "title" column nor the "data" column (since this
data is moved to "push_event_payloads").
== Newly Created Events
Newly created events are inserted into both "events" and
"events_for_migration", both using the exact same primary key value. The
table "push_event_payloads" in turn has a foreign key to the _shadow_
table. This removes the need for recreating and validating the foreign
key after swapping the tables. Since the shadow table also has a foreign
key to "projects.id" we also don't have to worry about orphaned rows.
This approach however does require some additional storage as we're
duplicating a portion of the events data for at least 1 release. The
exact amount is hard to estimate, but for GitLab.com this is expected to
be between 10 and 20 GB at most. The background migration in this commit
deliberately does _not_ update the "events" table as doing so would put
a lot of pressure on PostgreSQL's auto vacuuming system.
== Supporting Both Old And New Events
Application code has also been adjusted to support push events using
both the old and new data formats. This is done by creating a PushEvent
class which extends the regular Event class. Using Rails' Single Table
Inheritance system we can ensure the right class is used for the right
data, which in this case is based on the value of `events.action`. To
support displaying old and new data at the same time the PushEvent class
re-defines a few methods of the Event class, falling back to their
original implementations for push events in the old format.
Once all existing events have been migrated the various push event
related methods can be removed from the Event model, and the calls to
`super` can be removed from the methods in the PushEvent model.
The UI and event atom feed have also been slightly changed to better
handle this new setup, fortunately only a few changes were necessary to
make this work.
== API Changes
The API only displays push data of events in the new format. Supporting
both formats in the API is a bit more difficult compared to the UI.
Since the old push data was not really well documented (apart from one
example that used an incorrect "action" nmae) I decided that supporting
both was not worth the effort, especially since events will be migrated
in a few days _and_ new events are created in the correct format.
It is recommended that we set this to 50:
https://gitlab.com/gitlab-org/gitlab-ce/issues/35098#note_35036746
In this particular issue, the confidence was 42 for Shift JIS,
but in fact that's encoded in UTF-8 just with a single bad
character. In this case, we shouldn't try to treat it as Shift JIS,
but just treat it as UTF-8 and remove invalid bytes.
Treating it like Shift JIS would corrupt the whole data.
Unfortunately, the diff which would cause this could not be
disclosed therefore we can't use it as a test example.
The raw_log method is meant to become the Gitaly RPC boundary. By
setting the defaults before doing the RPC we keep the RPC
implementation simpler. We also sidestep the unfortunate subtleties of
what happens when options[:limit] is not set, or nil.
* master: (623 commits)
Fix issues with pdf-js dependencies
fix missing changelog entries for security release on 2017-01-23
Update top bar issues icon
Fix pipeline icon in contextual nav for projects
Since mysql is not a priority anymore, test it less
Fix order of CI lint ace editor loading
Add container registry and spam logs icons
Fix different Markdown styles
Backport to CE for:
Make new dropdown dividers full width
Fix spec
Fix spec
Fix spec
Bump GITLAB_SHELL_VERSION and GITALY_VERSION to support unhiding refs
Add changelog
Install yarn via apt in update guides
Use long curl options
fix
Add a spec for concurrent process
Remove monkey-patched Array.prototype.first() and last() methods
...
* upstream/master: (184 commits)
Fix issues with pdf-js dependencies
fix missing changelog entries for security release on 2017-01-23
Update top bar issues icon
Fix pipeline icon in contextual nav for projects
Since mysql is not a priority anymore, test it less
Fix order of CI lint ace editor loading
Add container registry and spam logs icons
Fix different Markdown styles
Backport to CE for:
Make new dropdown dividers full width
Fix spec
Fix spec
Fix spec
Bump GITLAB_SHELL_VERSION and GITALY_VERSION to support unhiding refs
Add changelog
Install yarn via apt in update guides
Use long curl options
fix
Add a spec for concurrent process
Remove monkey-patched Array.prototype.first() and last() methods
...
Previously, we stored these as serialised fields - `st_{commits,diffs}` - on the
`merge_request_diffs` table. These now have their own tables -
`merge_request_diff_{commits,diffs}` - with a column for each attribute of the
serialised data.
Add a background migration to go through the existing MR diffs and migrate them
to the new format. Ignore any contents that cannot be displayed. Assuming that
we have 5 million rows to migrate, and each batch of 2,500 rows can be
completed in 5 minutes, this will take about 7 days to migrate everything.
This would be much more accurate. We assume this is an
auto-generated email if such header is provided, and
the value is not "no". It could also be: "auto-generated",
"auto-replied", or other values from extension. It seems
that only "no" could mean that this is sent by a human.
See: https://tools.ietf.org/html/rfc3834
First iteration, and some stuff is missing. But basically this rake task
does a clone of a project we've pointed it to. Than creates a project on
the GDK, which should be running in the background. This project is
exported, after which we move that archive to the location we need it.
We clean up by removing the generated project.
The first idea was to export the project on .com too, however than we
might run into ImportExport versions mismatch. This could've been
circumvented by checkout out an older commit locally. This however is
not needed yet, so we opted to not go this route yet, instead we will
iterate on what we got.
Kamil Trzciński
Zeger-Jan van de Weg
Bob Van Landuyt
Shinya Maeda
Robert Speicher
Douwe Maan
Jacob Vosmaer
Grzegorz Bizon
Tiago Botelho
Dmitriy Zaporozhets
Alejandro Rodríguez
Sean McGivern
Sean McGivern
Nick Thomas
Kim "BKC" Carlbäcker
Hiroyuki Sato
Lin Jen-Shin
Yorick Peterse
Maxim Rydkin
James Lopez
Stan Hu
Andrew Newdigate
Douwe Maan
Ahmad Sherif
Robert Speicher
Gabriel Mazetto
Robin Bobbitt
Jarka Kadlecova
Felipe Artur
Rémy Coutable
vanadium23
Alexis Reigel
James Edwards-Jones
Brian Neel
Oswaldo Ferreira
Paweł Chojnacki
Douglas Barbosa Alexandre
Filipa Lacerda
Huang Tao
Tim Zallmann
Bob Van Landuyt