This finishes the procedure for migrating events from the old format
into the new format. Code no longer uses the old setup and the database
tables used during the migration process are swapped, with the old table
being dropped.
While the database migration can be reversed this will 1) take a lot of
time as data has to be coped around 2) won't restore data in the
"events.data" column as we have no way of restoring this.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/37241
The following optimizations were performed:
- Add new association to GroupMember and ProjectMember
This new association will allow us to check if a user is a member of a
Project or Group through a single query instead of two.
- Optimize retrieving of Members when adding multiple Users
this is used to make a difference between a committer email that belongs
to user, where the user used a different email for the gpg key. this
means that the user is the same, but a different, unverified email is
used for the signature.
This changes the issue and MR index pages so the pagination system
re-uses the output of the COUNT(*) query used to calculate the number of
rows per state (opened, closed, etc). This removes the need for an
additional COUNT(*) on both pages.
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
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
* commit '2be34630623711fc20ef8c101b5cef688f207cc1':
Common Docker Documentation Location in `gitlab-ce`
fix deprecation warning present during webpack compiles
Enable 5 lines of Sidekiq backtrace lines to aid in debugging
Add support for copying permalink to notes via more actions dropdown
Handle creating a nested group on MySQL correctly
Decrease statuses batch size even more in a migration
Fix repo editor scrollbar
Replace 'source/search_code.feature' spinach test with an rspec analog
Authorizations regarding OAuth - style confirmation
Update README.md
Refactor complicated API group finding rules into GroupsFinder
Fix group and project search for anonymous users
Document version Group Milestones API introduced
Allow v4 API GET requests for groups to be unauthenticated
Adjust a range and a size in stages statuses migration
Update README.md
Point to /developers on docs/administration/authentiq.md
Indexes GFM markdown guide
use inline links instead of referenced
Add index on ci_runners.contacted_at
There are some redundancies in the validation steps, and that is to
preserve current error messages behavior
Also few specs have to be changed in order to fix madness in validation
logic.
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.
* 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
...