| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Do not allow localhost url redirection in GitHub Integration
See merge request gitlab/gitlabhq!3188
|
|
Suggests to use a JSON structured log instead
Related to https://gitlab.com/gitlab-org/gitlab-ce/issues/54102
|
|
|
|
This sets up all the basics for importing Phabricator tasks into
GitLab issues.
To import all tasks from a Phabricator instance into GitLab, we'll
import all of them into a new project that will have its repository
disabled.
The import is hooked into a regular ProjectImport setup, but similar
to the GitHub parallel importer takes care of all the imports itself.
In this iteration, we're importing each page of tasks in a separate
sidekiq job.
The first thing we do when requesting a new page of tasks is schedule
the next page to be imported. But to avoid deadlocks, we only allow a
single job per worker type to run at the same time.
For now we're only importing basic Issue information, this should be
extended to richer information.
|
|
Issues and merge requests imported from GitHub are having state_id
set to null. This fixes the GitHub project importer and schedule
migrations to fix state_id.
|
|
|
|
After an initial fetch, the repository will have many loose objects
and refs. Running a `git gc` will compact refs into `packed-refs` and
objects into `.pack` files, which should make importing pull
requests faster.
Part of https://gitlab.com/gitlab-org/gitlab-ce/issues/59477
|
|
The project owner may actually be a group, in which case the branch
creation would fail due to a lack of username.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/59396
|
|
|
|
This avoids permission errors when importing merge requests whose
authors don't have direct access to push to the main repository.
|
|
|
|
|
|
When the GitHub importer creates a merge request, it retrieves the SHA
but does not actually create the source branch. This makes it impossible
to merge an open merge request, particularly if the source branch were
from a forked project. In that case, the branch will never exist because
the original `project-name:source-branch` name is never created, nor
is it a valid branch name.
To prevent possible branch name conflicts, forked source branches
are now renamed `github/fork/project-name/source-branch` and created
when necessary.
Note that we only create the source branch if the merge request
is open. For projects that have many merge requests, the project
would end up with a lot of possibly dead branches.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/57370
|
|
The previous behavior would pass in a list of parameters
to Shell, but we can improve this by using the WikiFormatter
and Project models to give us the same information.
|
|
When hashed storage is in use, it's helpful to have the project
name associated with the request.
Closes https://gitlab.com/gitlab-org/gitaly/issues/1394
|
|
|
|
This reverts commit b78a69b06c165f7a463d5e0de69030346d9d5c72.
|
|
This reverts commit 358675d09f6ba0fdcc4a089c6d1da6df9ff6d092.
|
|
Clears the import related columns and code from the Project
model over to the ProjectImportState model
|
|
This whitelists all existing offenses for the various CodeReuse cops, of
which most are triggered by the CodeReuse/ActiveRecord cop.
|
|
|
|
This in preparation for addressing idle-in-transaction timeouts for other importers.
Part of #50021
|
|
This refactors the AutocompleteController according to the guidelines
and boundaries discussed in
https://gitlab.com/gitlab-org/gitlab-ce/issues/49653. Specifically,
ActiveRecord logic is moved to different finders, which are then used in
the controller. View logic in turn is moved to presenters, instead of
directly using ActiveRecord's "to_json" method.
The finder MoveToProjectFinder is also adjusted according to the
abstraction guidelines and boundaries, resulting in a much more simple
finder.
By using finders (and other abstractions) more actively, we can push a
lot of logic out of the controller. We also remove the need for various
"before_action" hooks, though this could be achieved without using
finders as well.
The various finders related to AutcompleteController have also been
moved into a namespace. This removes the need for calling everything
"AutocompleteSmurfFinder", instead you can use
"Autocomplete::SmurfFinder".
|
|
|
|
|
|
|
|
Various counters would expose either project names, or full project
paths (e.g. "gitlab-org/gitlab-ce"). This commit changes various places
where we use "add_event" so we no longer expose (potentially) private
information.
|
|
|
|
In rare cases it could happen that an MR was created, but creating the
MR diffs somehow failed (e.g. due to an error). This commit adds an
additional check to make sure MR diffs are always present when importing
GitHub pull requests.
|
|
The cache state for Wikis that were imported via GitHub or Bitbucket does
not appear to have been flushed after a successful import.
Closes #47546
|
|
|
|
When importing a GitHub pull request we would perform all work in a
single database transaction. This is less than ideal, because we perform
various slow Git operations when creating a merge request. This in turn
can lead to many DB connections being used, while just waiting for an IO
operation to complete.
To work around this, we now move most of the heavy lifting out of the
database transaction. Some extra error handling is added to ensure we
can resume importing a partially imported pull request, instead of just
throwing an error.
This commit also changes the specs for IssueImporter so they don't rely
on deprecated RSpec methods.
|
|
|
|
Closes gitaly#1110
|
|
When a repository does not exist on a remote, Gitaly won't be able to
clone it. This is correct behaviour, but from the clients perspective a
change in behaviour.
This change implements the client side changes that allows Gitaly to
execute a `git ls-remote <remote-url> HEAD`. This way the client has no
need to shell out to Git.
In the situation where multiple Gitalies are available, one is chosen at
random.
This commit closes https://gitlab.com/gitlab-org/gitlab-ce/issues/43929,
while its also a part of https://gitlab.com/gitlab-org/gitaly/issues/1084
|
|
Also use Gitlab::Auth::OAuth::Provider.config_for to access OmniAuth config
|
|
|
|
|
|
|
|
with StrongMemoize
|
|
|
|
|
