#41341

https://gitlab.com/gitlab-org/gitlab-ce/issues/23036

https://gitlab.com/gitlab-org/gitlab-ce/issues/23036

We removed the exception handling for Rugged errors in !16770, which
revealed that the licensee gem attempts to retrieve a license file
via Rugged in `refs/heads/master` by default. If that branch
did not exist, a Rugged::ReferenceError would be thrown.

There were two issues:

1. Not every project uses `master` as the default branch. This
change uses the head commit to identify the license.

2. Removing the exception handling caused repositories to fail
loading. We can safely catch and ignore any Rugged error because
this means we weren't able to load a license file.

Closes #43268

Signed-off-by: Rémy Coutable <remy@rymai.me>

Before, this would:

1. Not use the correct reference for non-JIRA external trackers.
2. Append 'Closes ' if an external tracker was enabled, but no issue matched the
   branch name.

Signed-off-by: Rémy Coutable <remy@rymai.me>

And use :migration tag to use deletion strategy, and to avoid caching tables, and to lock into a particular schema.

Attempting to fix intermittent spec errors `PG::UndefinedTable: ERROR:  relation "public.untracked_files_for_uploads" does not exist`.

Adds i18n
Improves test cases

This essentially allows to pass both user and email, so that we can
either prefer the user to retrieve the avatar or (if user is not
present) fall back to the email lookup.

We want to drop the generic #avatar_icon helper that supports both an email
and a user object being passed in. Instead, we want to explicitly use the #avatar_icon_for_user
and #avatar_icon_for_email helpers depending on what we have at hand.
This allows us to avoid unnecessary database queries (e.g. call
User.find_by_any_email if we already have the user).

In situations like here, this makes it less convenient to use.

Whenever we already deal with a User object, let's use the more specific
method avatar_icon_for_user.

When we don't use the original `ApplicationHelper#avatar_icon` anymore, we
can just remove it (and its specs).

Closes #42800.

See https://gitlab.com/gitlab-org/gitlab-ce/issues/43198

Using Sentry, while useful, poses two problems you have to choose from:

1. All errors are reported separately, making it easy to create issues
   but also making it next to impossible to see other errors (due to the
   sheer volume of threshold errors).

2. Errors can be grouped or merged together, reducing the noise. This
   however also means it's (as far as I can tell) much harder to
   automatically create GitLab issues from Sentry for the offending
   controllers.

Since both solutions are terrible I decided to go with a third option:
not using Sentry for this at all. Instead we'll investigate using
Prometheus alerts and Grafana dashboards for this, which has the added
benefit of being able to more accurately measure the behaviour over
time.

Note that throwing errors in test environments is still enabled, and
whitelisting is still necessary to prevent that from happening (and that
in turn still requires that developers create issues).

Constructors shouldn't throw exceptions. We also learned that
different LDAP servers behave a bit unexpectedly sometimes -
returning attributes we didn't ask for, or returned attributes
with language subtypes.

Signed-off-by: Rémy Coutable <remy@rymai.me>

Closes #26466.

As per the discussion with @psimyn, this change does not affect the frontend, so user input will not be validated on the signin screen.

Instead, the value sent to the backend has leading and trailing whitespace stripped before looking up the user with find_by.

Closes #42637

When JIRA or Redmine were enabled and the branch name did not match the
matching regular expression, the `issue_iid` would be `nil`, preventing
users from creating merge requests.

Closes #43193