This will help diagnose the source of excessive I/O from Rugged
calls. To implement this, we need to obtain the full list of arguments
sent to each request method.
When passing start_branch on committing from the WebIDE, it's possible
that the branch has changed since editing started, which results in the
change being applied on top of the latest commit in the branch and
overwriting the new changes.
By passing the start_sha instead we can make sure that the change is
applied on top of the commit which the user started editing from.
Currently, MergeToRefService is specifically designed for
createing merge commits from source branch and target branch of
merge reqeusts. We extend this behavior to source branch and any
target ref paths.
It used to be the case that GitLab created symlinks for each repository
to one copy of the Git hooks, so these ran when required. This changed
to set the hooks dynamically on Gitaly when invoking Git.
The side effect is that we didn't need all these symlinks anymore, which
Gitaly doesn't create anymore either. Now that means that the tests in
GitLab-Rails should test for it either.
Related: https://gitlab.com/gitlab-org/gitaly/issues/1392#note_175619926
We want to optimize the query for the CountDivergingCommits rpc by
removing the --max-count argument now that we have commit graphs
enabled for all repositories during housekeeping. However, we want to
test this first behind a feature flag.
The new two-step Gitaly `Rebase` RPC yields the rebase commit SHA to the
client before proceeding with the rebase.
This avoids an issue where the rebase commit SHA was returned when the
RPC had fully completed, and in some cases this would be after the Rails
`post_receive` worker services had already run. In these situations,
the merge request did not yet have its rebase_commit_sha attribute set
introducing the possibility for bugs (such as previous approvals being
reset).
https://gitlab.com/gitlab-org/gitlab-ee/issues/5966
A temp reference is only needed to fetch a branch from another project,
as in the case for forked repositories. For branch comparisons within
the same project, we can just use the existing branch names to do the
comparison.
Relates to https://gitlab.com/gitlab-org/gitlab-ce/issues/38689#note_126107862
Add `GetArchiveRequest` to git-archive params.
Modifies `Git::Repository#archive_metadata` to append `path`
to `ArchivePrefix` so it'll not hit the cache of repository archive
when it already exists.
EE added the ability to set timeouts when handling blobs. Since there's
no particular reason for this to be EE specific we can just backport
this to CE.
When `force` is set to `true` and `start_branch` is set, the
branch will be ovewritten with the new commit based on the
`HEAD` of the `start_branch`.
This commit includes changes to update the `gitaly-proto` gem.
This brings back some of the changes in
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20339.
For users using Gitaly on top of NFS, accessing the Git data directly
via Rugged is more performant than Gitaly. This merge request introduces
the feature flag `rugged_find_commit` to activate Rugged paths.
There are also Rake tasks `gitlab:features:enable_rugged` and
`gitlab:features:disable_rugged` to enable/disable these feature
flags altogether.
Part of four Rugged changes identified in
https://gitlab.com/gitlab-org/gitlab-ce/issues/57317.
Adds the ground work for writing into
the merge ref refs/merge-requests/:iid/merge the
merge result between source and target branches of
a MR, without further side-effects such as
mailing, MR updates and target branch changes.
When a project is forked, the new repository used to be a deep copy of everything
stored on disk by leveraging `git clone`. This works well, and makes isolation
between repository easy. However, the clone is at the start 100% the same as the
origin repository. And in the case of the objects in the object directory, this
is almost always going to be a lot of duplication.
Object Pools are a way to create a third repository that essentially only exists
for its 'objects' subdirectory. This third repository's object directory will be
set as alternate location for objects. This means that in the case an object is
missing in the local repository, git will look in another location. This other
location is the object pool repository.
When Git performs garbage collection, it's smart enough to check the
alternate location. When objects are duplicated, it will allow git to
throw one copy away. This copy is on the local repository, where to pool
remains as is.
These pools have an origin location, which for now will always be a
repository that itself is not a fork. When the root of a fork network is
forked by a user, the fork still clones the full repository. Async, the
pool repository will be created.
Either one of these processes can be done earlier than the other. To
handle this race condition, the Join ObjectPool operation is
idempotent. Given its idempotent, we can schedule it twice, with the
same effect.
To accommodate the holding of state two migrations have been added.
1. Added a state column to the pool_repositories column. This column is
managed by the state machine, allowing for hooks on transitions.
2. pool_repositories now has a source_project_id. This column in
convenient to have for multiple reasons: it has a unique index allowing
the database to handle race conditions when creating a new record. Also,
it's nice to know who the host is. As that's a short link to the fork
networks root.
Object pools are only available for public project, which use hashed
storage and when forking from the root of the fork network. (That is,
the project being forked from itself isn't a fork)
In this commit message I use both ObjectPool and Pool repositories,
which are alike, but different from each other. ObjectPool refers to
whatever is on the disk stored and managed by Gitaly. PoolRepository is
the record in the database.
Use shelling out to git to write refs instead of rugged, hoping to
avoid creating invalid refs.
To update HEAD we switched to using `git symbolic-ref`.
Having this in a concern allows us to reuse it for different single
purpose classes that call out to git without going through the
repository every time.
Was introduced in the time that GitLab still used NFS, which is not
required anymore in most cases. By removing this, the API it calls will
return empty responses. This interface has to be removed in the next
major release, expected to be 12.0.
Cleanup code, and refactor tests that still use Rugged. After this, there should
be no Rugged code that access the instance's repositories on non-test
environments. There is still some rugged code for other tasks like the
repository import task, but since it doesn't access any repository storage path
it can stay.
Implements list_last_commits_for_tree to communicate with the
ListLastCommitsForTree Gitaly RPC
Bumps the Gitaly server version
Bumps the Gitaly-Proto gem version
This old migration used Rugged to find a commit, while Gitaly is the
prefered way now. By migrating this to Gitaly, Gitaly is now a required
running component for this migration.
Part of https://gitlab.com/gitlab-org/gitaly/issues/1106
After trying to remove the whole method in
8f69014af2902d8d53fe931268bec60f6858f160, this is a more gentle
approach to the method. :)
Prior to this change, new commit detection wasn't implemented in Gitaly,
this was done through: https://gitlab.com/gitlab-org/gitaly/merge_requests/779
As the new implemented got moved around a bit, the whole RevList class
got removed.
Part of https://gitlab.com/gitlab-org/gitaly/issues/1233
Prior to this change, most the commits counted were done through Gitaly.
This removes the last point where this wasn't the case.
This makes the `rugged_count_commits` method obsolete, with its tests.
Closes https://gitlab.com/gitlab-org/gitaly/issues/315
GitLab Bot
dineshpanda
Stan Hu
Markus Koller
Igor
Mayra Cabrera
Shinya Maeda
GitalyBot
Luke Duncalfe
Patrick Bajao
Zeger-Jan van de Weg
John Cai
Bob Van Landuyt
Oswaldo Ferreira
Nick Thomas
Rémy Coutable
Yorick Peterse
Douwe Maan
Andrew Newdigate
Oswaldo Ferreira
Douwe Maan
Sean McGivern
Takuya Noguchi
gfyoung
Francisco Javier López
Alejandro Rodríguez
Tiago Botelho
Douglas Barbosa Alexandre
Rubén Dávila
Jacob Vosmaer (GitLab)
Sean McGivern
Lin Jen-Shin
Robert Speicher
Grzegorz Bizon