Saved Wiki content goes through the GitalyClient::WikiService, which calls
StringIO#set_encoding on the input stream. The problem is that this call
mutates the encoding of the given string object to ASCII-88BIT, which
causes problems for models expecting the data to still be in UTF-8.

Freezing the input disables this behavior:
https://github.com/ruby/ruby/blob/v2_4_4/ext/stringio/stringio.c#L1583

Closes #50590

Closes #50405

These don't have performance data saved as they use Grape.

Sean McGivern authored 6 years ago and Jose Ivan Vargas Lopez committed 6 years ago

Previously, this wasn't needed: text was normally set to the highlighted
contents anyway. Now, it is: we store different things in text and rich_text.

This caused https://gitlab.com/gitlab-com/production/issues/439.

Stan Hu authored 6 years ago and Jose Ivan Vargas Lopez committed 6 years ago

Closes https://gitlab.com/gitlab-com/migration/issues/766

Filipa Lacerda authored 6 years ago and Jose Ivan Vargas Lopez committed 6 years ago

When backend sends HTML it requires frontend to append it to the DOM causing
XSS vulnerabilities. By removing the `<br>` we avoid those vulnerabilities

Previously, this wasn't needed: text was normally set to the highlighted
contents anyway. Now, it is: we store different things in text and rich_text.

This caused https://gitlab.com/gitlab-com/production/issues/439.

Just like with the GitHub importer, the Bitbucket Server importer can hit the
default 60 s idle-in-transaction timeouts if it takes too long to create the
merge request. We solve this by using the same approach as the GitHub importer:

1. Bypass all validation and hooks in creating a merge request
2. Insert the Git data in a separate transaction

Part of #50021

When using ruby interpolation in externalized strings, they can't be
detected. Which means they will never be presented to be translated.

To mix variables into translations we need to use `sprintf`
instead.

Instead of:

    _("Hello #{subject}")

Use:

    _("Hello %{subject}) % { subject: 'world' }

Users importing from Bitbucket Cloud, Bitbucket Server, or GitHub
often complained about getting failed imports due to 422 errors.
This change ensures that project names are imported with names that
are guaranteed to pass the regular expression validation.

Part of #50021

This in preparation for addressing idle-in-transaction timeouts for other importers.

Part of #50021

Remote mirrors only get created when the URL changes, However, during the GCP
migration, the remote mirror did not get created automatically. Plus, there's
no guarantee someone restoring a repository from backup would have this
remote. We now add the remote each time we attempt to fetch from the
repository.

This works because Gitaly doesn't throw up an exception or error if the
remote already exists:
https://gitlab.com/gitlab-org/gitaly/issues/1317

In the future, we should attempt to add if the remote doesn't exist:
https://gitlab.com/gitlab-org/gitaly/issues/1316

Closes #50562

Due to a regression in !20608, the LDAP authenticator was not being used
unless OmniAuth was enabled. This change allows the LDAP provider to be used
if it is configured regardless of the OmniAuth setting.

Closes #50579

This fixes a regression in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20916.
We now only use the full commit count for the initial push to the default branch.
Otherwise, we rely on the number of commits that we calculated occurred in the push.

The original behavior in 11.1.4:

1. When a new branch is pushed, `@push_commits_count` was set to the total
number of refs available for the branch.
2. For other branches, `@push_commits_count` would remain `nil`.
3. `GitPushService#build_push_data` would build the push data with
`@push_commits_count`.
4. If this were `nil`, it would be set to the right value here:
https://gitlab.com/gitlab-org/gitlab-ce/blob/v11.1.4/lib/gitlab/data_builder/push.rb#L60

Broken behavior:

1. `GitPushService#push_commits_count` is always called.
2. The total number of commits is therefore always equal to the total number of refs available.

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/49971