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

Fix #47913 (again), revert !21180, fix regression of !8652, improve !20137

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

GitLab Release Tools Bot authored 6 years ago and Jose Ivan Vargas Lopez committed 6 years ago

[ci skip]

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

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

[ci skip]

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

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

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

[ci skip]

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

When a diff has a significant number of commits, the previous behavior would
attempt to render the Markdown on all the commit messages but only display
1000 of them. To avoid additional work, we only need to render the Markdown
on the set that is displayed.

- Allow `created_at` and `updated_at` parameters on Issues API
- Allow `created_at` on Issue Notes API

Closes gitlab-org/gitlab-ce#40059

[ci skip]