delta/gitlab/gitlab-ce.git/app/services/projects, branch docs/add_file_diff_description gitlab.com: gitlab-org/gitlab-ce.git Merge branch 'master' of dev.gitlab.org:gitlab/gitlabhq 2019-08-29T22:17:37+00:00 Robert Speicher rspeicher@gmail.com 2019-08-29T22:17:37+00:00 7698d405506bc10dfd7fb2e6e02b419dd5925725 






Merge branch 'security-project-import-bypass' into 'master'
2019-08-29T21:34:04+00:00

GitLab Release Tools Bot
robert+release-tools@gitlab.com

2019-08-29T21:34:04+00:00

7d6edff6f3c7483ac588160bdf4e43ec8d0ad5d9

Project visibility restriction bypass

See merge request gitlab/gitlabhq!3306




Project visibility restriction bypass

See merge request gitlab/gitlabhq!3306






Makes LFS object linker process OIDs in batches
2019-08-27T22:52:33+00:00

Stan Hu
stanhu@gmail.com

2019-08-27T13:07:38+00:00

2022e6799bcbf119ea80145e4993ffdb7bb108e3

During a project import, `LfsLinkService` attempts to link `LfsObjects`
that have not already been associated with a project.  It's possible for
a large repo to have thousands of OIDs, which can cause long database
query and parsing times.  By processing a batch of 1000 at a time, we
can reduce that time at the expense of a few more SQL queries.

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





During a project import, `LfsLinkService` attempts to link `LfsObjects`
that have not already been associated with a project.  It's possible for
a large repo to have thousands of OIDs, which can cause long database
query and parsing times.  By processing a batch of 1000 at a time, we
can reduce that time at the expense of a few more SQL queries.

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







Allow disabling group/project email notifications
2019-08-15T17:37:36+00:00

Brett Walker
bwalker@gitlab.com

2019-08-15T17:37:36+00:00

3489dc3d7277bf478f68e1b3e0353b702f652acc

- Adds UI to configure in group and project settings
- Removes notification configuration for users when
disabled at group or project level





- Adds UI to configure in group and project settings
- Removes notification configuration for users when
disabled at group or project level







Fix project import restricted visibility bypass
2019-08-15T09:30:47+00:00

George Koltsov
gkoltsov@gitlab.com

2019-08-06T13:05:18+00:00

06eddc3edfa739c0c685d461a58621b43c4ecd5d

Add Gitlab::VisibilityLevelChecker that verifies
selected project visibility level (or overridden param)
is not restricted when creating or importing a project





Add Gitlab::VisibilityLevelChecker that verifies
selected project visibility level (or overridden param)
is not restricted when creating or importing a project







Rework retry strategy for remote mirrors
2019-08-13T20:52:01+00:00

Bob Van Landuyt
bob@gitlab.com

2019-08-13T20:52:01+00:00

452bc36d603ed89d3fa5e3409338dd905230bd2f

**Prevention of running 2 simultaneous updates**

Instead of using `RemoteMirror#update_status` and raise an error if
it's already running to prevent the same mirror being updated at the
same time we now use `Gitlab::ExclusiveLease` for that.

When we fail to obtain a lease in 3 tries, 30 seconds apart, we bail
and reschedule. We'll reschedule faster for the protected branches.

If the mirror already ran since it was scheduled, the job will be
skipped.

**Error handling: Remote side**

When an update fails because of a `Gitlab::Git::CommandError`, we
won't track this error in sentry, this could be on the remote side:
for example when branches have diverged.

In this case, we'll try 3 times scheduled 1 or 5 minutes apart.

In between, the mirror is marked as "to_retry", the error would be
visible to the user when they visit the settings page.

After 3 tries we'll mark the mirror as failed and notify the user.

We won't track this error in sentry, as it's not likely we can help
it.

The next event that would trigger a new refresh.

**Error handling: our side**

If an unexpected error occurs, we mark the mirror as failed, but we'd
still retry the job based on the regular sidekiq retries with
backoff. Same as we used to

The error would be reported in sentry, since its likely we need to do
something about it.





**Prevention of running 2 simultaneous updates**

Instead of using `RemoteMirror#update_status` and raise an error if
it's already running to prevent the same mirror being updated at the
same time we now use `Gitlab::ExclusiveLease` for that.

When we fail to obtain a lease in 3 tries, 30 seconds apart, we bail
and reschedule. We'll reschedule faster for the protected branches.

If the mirror already ran since it was scheduled, the job will be
skipped.

**Error handling: Remote side**

When an update fails because of a `Gitlab::Git::CommandError`, we
won't track this error in sentry, this could be on the remote side:
for example when branches have diverged.

In this case, we'll try 3 times scheduled 1 or 5 minutes apart.

In between, the mirror is marked as "to_retry", the error would be
visible to the user when they visit the settings page.

After 3 tries we'll mark the mirror as failed and notify the user.

We won't track this error in sentry, as it's not likely we can help
it.

The next event that would trigger a new refresh.

**Error handling: our side**

If an unexpected error occurs, we mark the mirror as failed, but we'd
still retry the job based on the regular sidekiq retries with
backoff. Same as we used to

The error would be reported in sentry, since its likely we need to do
something about it.







Fix :wiki_can_not_be_created_total counter
2019-08-09T14:52:38+00:00

Aleksei Lipniagov
alipniagov@gitlab.com

2019-08-09T14:46:55+00:00

3c25e8734f137d5e32d0cce4ec4cd95e90a39d07












Don't attempt to contact registry if it is disabled
2019-08-06T20:44:26+00:00

Stan Hu
stanhu@gmail.com

2019-08-06T20:36:07+00:00

35ce4820f24c15a5c7bdb111d73a90fd9bea2655

https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21679 moved the
deletion of registry tags outside of a transaction, but introduced an
issue where Sidekiq would attempt to contact the container registry
during project destruction even if it were disabled.

Relates to:

* https://gitlab.com/charts/gitlab/issues/1455
* https://gitlab.com/gitlab-org/gitlab-ce/issues/45941





https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21679 moved the
deletion of registry tags outside of a transaction, but introduced an
issue where Sidekiq would attempt to contact the container registry
during project destruction even if it were disabled.

Relates to:

* https://gitlab.com/charts/gitlab/issues/1455
* https://gitlab.com/gitlab-org/gitlab-ce/issues/45941







Ignore Gitaly errors if cache flushing fails on project destruction
2019-07-30T06:05:03+00:00

Stan Hu
stanhu@gmail.com

2019-07-25T23:15:00+00:00

9c2baada57a6a4c6746ce9fa37ec33d94e2dff09

We should just ignore these errors and move along with the deletion
since the repositories are going to be trashed anyway.

Closes https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/31164





We should just ignore these errors and move along with the deletion
since the repositories are going to be trashed anyway.

Closes https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/31164







Refactor and remove #prepare_relation method
2019-07-29T10:47:06+00:00

Andreas Brandl
abrandl@gitlab.com

2019-07-27T14:59:35+00:00

b9af5066eaadda217224ba2037db72bfc9ee440c

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





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