| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
This means we have one less Net::HTTP monkeypatch.
sham_rack cannot handle IPv6 addresses which means it breaks Net::HTTP
connections because it monkey-patches Net::HTTP
|
| |
|
|
|
| |
These are not required because MySQL is not
supported anymore
|
| |
|
|
|
| |
Pages access level currently depends on project visibilty
which is ignored by factory, this commit fixes that
|
| |
|
|
|
|
|
|
|
|
| |
When the SQL query cache is active, the SELECT query for finding
projects to apply service templates returns the same values. This causes
an infinite loop because even though bulk INSERT queries are made, the
cached results never reflect that progress. To fix this, we call
`Project.uncached` around the query to ensure new data is retrieved.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/63595
|
| |
|
|
| |
updated documentation for Geo
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider the scenario:
1. The default visibility level is set to internal
2. A user attempts to create a private project within a private group
Previously this would always fail because default_value_for would
overwrite the private visibility setting, no matter what
visibility_level were specified. This was happening because
default_value_for was confused by the default value of 0 specified by
the database schema.
default_value_for attempts to assign the default value in the block by
checking whether the attribute has changed. The problem is that since
the default value by the database was 0, and the user requested 0, this
appeared as though no changes were made. As a result, default_value_for
would always overwrite the user's preference.
To fix this, we remove the use of default_value_for and only set the
visibility level to the default application setting when no preference
has been given at creation time.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/63158
|
| |
|
|
|
|
|
|
|
|
| |
Enable Get and Update of ci_default_git_depth for
Project API.
Renaming Project#default_git_depth to :ci_default_git_depth
to give more context through the API usage.
Add API documentation
|
| |
|
|
|
| |
If the origin project has no default_git_depth set (i.e. nil) set the
fork's default_git_depth to 0
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce default_git_depth in project's CI/CD settings and set it to
50. Use it if there is no GIT_DEPTH variable specified. Apply this
default only to newly created projects and keep it nil for old ones
in order to not break pipelines that rely on non-shallow clones.
default_git_depth can be updated from CI/CD Settings in the UI, must be
either nil or integer between 0 and 1000 (incl).
Inherit default_git_depth from the origin project when forking projects.
MR pipelines are run on a MR ref (refs/merge-requests/:iid/merge) and it
contains unique commit (i.e. merge commit) which doesn't exist in the
other branch/tags refs. We need to add it cause otherwise it may break
pipelines for old projects that have already enabled Pipelines for merge
results and have git depth 0.
Document new default_git_depth project CI/CD setting
|
| |
|
|
|
| |
Delete Todos for guest users when project visibility
level is updated to private.
|
| |\ |
|
| | |
| |
| |
| |
| |
| | |
Gitlab::HTTP now resolves the hostname only once, verifies the IP is not
blocked, and then uses the same IP to perform the actual request, while
passing the original hostname in the `Host` header and SSL SNI field.
|
| | |
| |
| |
| |
| |
| | |
We've already migrated all the legacy artifacts to the new realm,
which is ci_job_artifacts table.
It's time to remove the old code base that is no longer used.
|
| |/ |
|
| |
|
|
|
| |
GitDeduplicationService performs idempotent operations on deduplicated
projects.
|
| |
|
|
|
|
|
|
|
|
|
| |
Immediate configuration is not ideal for group and instance
level clusters as projects that may never be deployed would
still have Kubernetes namespaces and service accounts created
for them.
As of https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/25586
we now create only the resources that are required for the
project being deployed, at the time of deployment.
|
| |\
| |
| |
| |
| |
| |
| | |
Properly handle LFS Batch API response in project import
Closes #61624
See merge request gitlab-org/gitlab-ce!28223
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Project imports were failing with `undefined method each_with_object for
String` because the import was attempting to parse the LFS Batch API and
failing due to the fact that the Content-Type wasn't a supported format
(e.g. application/vnd.git-lfs+json instead of application/json). We now
parse the body as JSON.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/61624
|
| |/
|
|
|
|
|
|
|
| |
Pull mirrors would run the `Projects::AfterImportService`, which would
force a `git gc` each time it finished. This is overkill and not
necessary now that we have refs packed more frequently
(https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/27826).
Closes https://gitlab.com/gitlab-org/gitlab-ee/issues/11556
|
| |
|
|
| |
Fixes #60425
|
| | |
|
| |
|
|
|
|
|
|
| |
PackRefs is not an expensive gitaly call - we want to
call it more often (than as part of full `gc`) because
it helps to keep number of refs files small - too many
refs file may be a problem for deployments with
slow storage.
|
| |
|
|
|
|
| |
In order to make `LfsImportService` more reusable, we
need to extract the logic inside `ImportService` and
encapsulate it into the service.
|
| |
|
|
|
|
| |
This new table will be used to store the external_dashboard_url which
allows users to add a link to their external dashboards (ex Grafana)
to the Metrics dashboard.
|
| | |
|
| |
|
|
| |
Probably useful as we often move these files to "new" files.
|
| |
|
|
| |
spec/features/groups/group_page_with_external_authorization_service_spec to EE
|
| |\
| |
| |
| |
| | |
Fix the bug that the project statistics is not updated
See merge request gitlab-org/gitlab-ce!26854
|
| | | |
|
| | |
| |
| | |
This reverts merge request !26823
|
| | |
| |
| |
| | |
spec/features/groups/group_page_with_external_authorization_service_spec to EE
|
| |/
|
|
|
|
|
| |
- rewords examples starting with 'should'
- rewords examples starting with 'it'
Note: I had to manually fixup "onlies" to "only"
|
| |\
| |
| |
| | |
jarv/dev-to-gitlab-2019-04-02
|
| | |\
| | |
| | |
| | |
| | | |
Return cached languages if they've been detected before
See merge request gitlab/gitlabhq!2998
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
During a project import, it's possible that new branches are created by
the importer to handle pull requests that have been created from forked
projects, which would increment the `pushes_since_gc` value via
`HousekeepingService.increment!` before a full garbage collection gets
to run. This causes HousekeepingService to skip the full `git gc` and
move to the incremental repack mode. To ensure that a garbage collection
is run to pack refs and objects, explicitly execute the task.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/59477
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Both of these were related to groups:
1. We need to preload routes (using the `with_route` scope) if we're
going to get the group's path.
2. We were counting each group's members separately.
They're in the same commit because the spec for N+1 detection wouldn't
pass with only one of these fixes.
|
| |/
|
|
|
| |
The flag is on by default, but allows us to revert back
to the old behaviour if we encounter any problems.
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
Resolve "Hashed storage migration should not be attempted if project does not validate"
Closes #56618
See merge request gitlab-org/gitlab-ce!25753
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is a fix for the Hashed Storage migration and Rollback procedure
to ignore any project-level validation error that can happen in a
long-running instance.
There are many situations where defaults and acceptable values changed
but, because we didn't provide a migration to "valid" attributes, it
can happen that project will not be `valid? => true`.
Because the changes we are making are limited to setting a project as
read_only or changing the storage_level, it's safe to bypass validation.
|
| |\ \
| |/
|/| |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
into 'master'
Hashed Storage rollback mechanism
See merge request gitlab-org/gitlab-ce!23955
|
| | | |
| | |
| | |
| | | |
Exceptions were also simplified from 2 to 1.
|
| | | |
| | |
| | |
| | |
| | | |
`try_to_set_repository_read_only!` is now on the Base class.
Simplified Exception classes from 2 to 1 with a more descriptive name.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This change takes the case where repository doesn't exist on disk
and make it ignore but succeed the step, increasing or decreasing the
version depending on the operation.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Rollback is done similar to Migration for the Hashed Storage.
It also shares the same ExclusiveLease key to prevent both happening
at the same time.
All Hashed Storage related workers now share the same queue namespace
which allows for assigning dedicated workers easily.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
We are adding sidekiq workers and service classes to allow to rollback
a hashed storage migration. There are some refactoring involved as well
as part of the code can be reused by both the migration and the rollback
logic.
|
