| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
Resolve "Cannot rename a hashed project"
Closes #38202
See merge request gitlab-org/gitlab-ce!14428
|
| | | |
|
| | | |
|
| |\ \
| |/
|/|
| |
| | |
Move Fast-Forward Merge to CE
See merge request gitlab-org/gitlab-ce!14272
|
| | |\ |
|
| | |\ \
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
app/models/project.rb
db/schema.rb
|
| | |\ \ \ |
|
| | | | | | |
|
| | |_|_|/
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Because of a change in GitLab 9.5.4 to prevent users from assuming control of
a repository already on disk, the import task broke. Imports would fail with
the message, "There is already a repository with that name on disk".
This change skips the validation when the import is done from the
command-line.
Closes #37682
|
| | | | | |
|
| | |_|/
|/| |
| | |
| | | |
Closes gitaly#601
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Clear merge requests counter cache after merge
Closes gitlab-ee#3573 and #38344
See merge request gitlab-org/gitlab-ce!14563
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Before this change, the MR counter in the sidebar would be wrong if an MR had
been merged since the last update, but not opened or closed, as merging did not
trigger a counter cache update.
|
| |/ / / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Refactor services to match EE signature
See merge request gitlab-org/gitlab-ce!14385
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | | |
Clean merge_jid whenever necessary on the merge process
Closes #38476
See merge request gitlab-org/gitlab-ce!14540
|
| | | |/
| |/|
| | |
| | | |
MergeRequest#merge_jid should be cleaned up whenever we hit a known error on MergeService#execute. This way we can keep track if the MR is really "ongoing" or "stuck"
|
| | | |
| | |
| | |
| | | |
Closes gitlab-org/gitlab-ce#34415
|
| | | | |
|
| |/ / |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Stop using Sidekiq for updating Key#last_used_at
Closes #36663
See merge request gitlab-org/gitlab-ce!14391
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This makes things simpler as no scheduling is involved. Further we
remove the need for running a SELECT + UPDATE just to get the key and
update it, whereas we only need an UPDATE when setting last_used_at
directly in a request.
The added service class takes care of updating Key#last_used_at without
using Sidekiq. Further it makes sure we only try to obtain a Redis lease
if we're confident that we actually need to do so, instead of always
obtaining it. We also make sure to _only_ update last_used_at instead of
also updating updated_at.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/36663
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | | |
Fix refreshing of issues/MR count caches
Closes #38061
See merge request gitlab-org/gitlab-ce!14363
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This ensures the open issues/MR count caches are refreshed properly when
creating new issues or MRs. This MR also includes a change to the cache
keys to ensure all caches are rebuilt on the fly.
This particular problem was not caught in the test suite due to a null
cache being used, resulting in all calls that would use a cache using
the underlying data directly. In production the code would fail because
a newly saved record returns an empty hash in #changes meaning checks
such as `state_changed? || confidential_changed?` would return false for
new rows, thus never updating the counters.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/38061
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| | |
Prepare Repository#merge for migration to Gitaly
Closes gitaly#559
See merge request gitlab-org/gitlab-ce!14154
|
| | | |
|
| |\ \
| | |
| | |
| | | |
# Conflicts:
# db/schema.rb
|
| | |/ |
|
| | |\
| | |
| | |
| | |
| | | |
Optimize some tests with RSpec Set
See merge request !14047
|
| | | | |
|
| | | | |
|
| | |/ |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This enables skipping a lesser housekeeping task
(incremental or full repack) by consistently
scheduling a higher task (respectively full repack or gc)
with the same period.
Cf. #34981
|
| | | |
|
| |/
|
|
| |
visibility level
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Whenever you push to a branch GitLab will show a button to create a
merge request (should one not exist already). The underlying code to
display this data was quite inefficient. For example, it involved
multiple slow queries just to figure out what the most recent push event
was.
This commit changes the way this data is retrieved so it's much faster.
This is achieved by caching the ID of the last push event on every push,
which is then retrieved when loading certain pages. Database queries are
only executed if necessary and the cached data is removed automatically
once a merge request has been created, or 2 hours after being stored.
A trade-off of this approach is that we _only_ track the last event.
Previously if you were to push to branch A and B then create a merge
request for branch B we'd still show the widget for branch A. As of this
commit this is no longer the case, instead we will only show the widget
for the branch you pushed to most recently. Once a merge request exists
the widget is no longer displayed. Alternative solutions are either too
complex and/or too slow, hence the decision was made to settle for this
trade-off.
Performance Impact
------------------
In the best case scenario (= a user didn't push anything for more than 2
hours) we perform a single Redis GET per page. Should there be cached
data we will run a single (and lightweight) SQL query to get the
event data from the database. If a merge request already exists we will
run an additional DEL to remove the cache key.
The difference in response timings can vary a bit per project. On
GitLab.com the 99th percentile of time spent in User#recent_push hovers
between 100 milliseconds and 1 second, while the mean hovers around 50
milliseconds. With the changes in this MR the expected time spent in
User#recent_push is expected to be reduced down to just a few
milliseconds.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/35990
|
| |\
| |
| |
| |
| |
| |
| |
| |
| | |
'30473-allow-creation-of-subgroups-with-gitlab_default_can_create_group-set-to-false' into 'master'
Make Members with Owner and Master roles always able to create subgroups
Closes #30473
See merge request !14046
|
| | | |
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| | |
'35558-only-one-garbage-collection-should-be-running-per-project-at-once' into 'master'
Adds exclusive lease to Git garbage collect worker.
Closes #35558
See merge request !14036
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Improve "Share with group lock" feature for subgroups
Closes #30550
See merge request !13944
|
| | | | |
|
| | | | |
|
| | |/
| |
| |
| | |
…in Groups::UpdateService instead of only in the browser.
|
