Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
1f92a1f626
commit
0c61097d12
|
|
@ -0,0 +1,30 @@
|
|||
# The gdk-update job boots into an existing GDK (GitLab Development Kit)
|
||||
# installation. We then run `gdk update` to update the installation as if
|
||||
# the current branch was already merged to master.
|
||||
#
|
||||
# The point of this job is to ensure that changes in this repository
|
||||
# don't break the development flow of contributors.
|
||||
gdk-update:
|
||||
image: registry.gitlab.com/gitlab-org/gitlab-development-kit/mise-bootstrapped-gdk-installed:main
|
||||
needs: []
|
||||
tags:
|
||||
- $GITLAB_LARGE_RUNNER_OPTIONAL
|
||||
extends:
|
||||
- .default-retry
|
||||
- .gdk:rules:gdk-update
|
||||
allow_failure: true # See https://gitlab.com/gitlab-org/gitlab-development-kit/-/issues/2788
|
||||
variables:
|
||||
GIT_STRATEGY: none
|
||||
GEM_HOME: /home/gdk/.gitlab-ci-cache/ruby/gem
|
||||
GEM_PATH: /home/gdk/.gitlab-ci-cache/ruby/gem
|
||||
RAILS_ENV: development
|
||||
ENABLE_BOOTSNAP: "false"
|
||||
PUMA_SINGLE_MODE: "true"
|
||||
GDK_DEBUG: "true"
|
||||
BUNDLE_WITHOUT: production
|
||||
script:
|
||||
- unset BUNDLER_CHECKSUM_VERIFICATION_OPT_IN
|
||||
- cd /home/gdk/gdk/gitlab
|
||||
- git remote set-url origin "$CI_REPOSITORY_URL"
|
||||
- gdk config set gitlab.default_branch "$CI_COMMIT_SHA"
|
||||
- gdk update
|
||||
|
|
@ -786,6 +786,9 @@
|
|||
- GITLAB_SHELL_VERSION
|
||||
- GITALY_SERVER_VERSION
|
||||
|
||||
.gdk-update-patterns: &gdk-update-patterns
|
||||
- .gitlab/ci/gdk.gitlab-ci.yml
|
||||
|
||||
.ruby-version-patterns: &ruby-version-patterns
|
||||
- ".ruby-version"
|
||||
- ".tool-versions"
|
||||
|
|
@ -3210,6 +3213,23 @@
|
|||
- <<: *if-default-refs
|
||||
changes: *workhorse-patterns
|
||||
|
||||
#############
|
||||
# GDK rules #
|
||||
#############
|
||||
.gdk:rules:gdk-update:
|
||||
rules:
|
||||
- <<: *if-not-canonical-namespace
|
||||
when: never
|
||||
- <<: *if-merge-request-labels-pipeline-expedite
|
||||
when: never
|
||||
- <<: *if-default-refs
|
||||
changes: *gdk-update-patterns
|
||||
- <<: *if-default-refs
|
||||
changes: *ruby-version-patterns
|
||||
- !reference [".prevent-tier-2-and-below", "rules"]
|
||||
- <<: *if-default-refs
|
||||
changes: *setup-test-env-patterns
|
||||
|
||||
###################
|
||||
# yaml-lint rules #
|
||||
###################
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
|
||||
include:
|
||||
- project: gitlab-org/quality/pipeline-common
|
||||
ref: 11.1.1
|
||||
ref: 11.6.1
|
||||
file:
|
||||
- /ci/base.gitlab-ci.yml
|
||||
|
||||
|
|
|
|||
|
|
@ -2,26 +2,6 @@
|
|||
# Cop supports --autocorrect.
|
||||
Layout/ArrayAlignment:
|
||||
Exclude:
|
||||
- 'ee/app/services/vulnerabilities/create_service_base.rb'
|
||||
- 'ee/lib/gitlab/analytics/cycle_analytics/summary/group/stage_summary.rb'
|
||||
- 'ee/lib/gitlab/usage/metrics/instrumentations/license_metric.rb'
|
||||
- 'ee/spec/controllers/admin/licenses/usage_exports_controller_spec.rb'
|
||||
- 'ee/spec/features/boards/boards_licensed_features_spec.rb'
|
||||
- 'ee/spec/features/groups/analytics/cycle_analytics/charts_spec.rb'
|
||||
- 'ee/spec/features/groups/group_roadmap_spec.rb'
|
||||
- 'ee/spec/finders/security/pipeline_vulnerabilities_finder_spec.rb'
|
||||
- 'ee/spec/frontend/fixtures/search.rb'
|
||||
- 'ee/spec/graphql/resolvers/analytics/contribution_analytics/contributions_resolver_spec.rb'
|
||||
- 'ee/spec/graphql/types/dast_scanner_profile_type_spec.rb'
|
||||
- 'ee/spec/lib/gitlab/graphql/loaders/oncall_participant_loader_spec.rb'
|
||||
- 'ee/spec/lib/gitlab/visibility_level_spec.rb'
|
||||
- 'ee/spec/lib/incident_management/oncall_shift_generator_spec.rb'
|
||||
- 'ee/spec/models/dora/base_metric_spec.rb'
|
||||
- 'ee/spec/models/dora/daily_metrics_spec.rb'
|
||||
- 'ee/spec/models/ee/group_spec.rb'
|
||||
- 'ee/spec/models/ee/project_spec.rb'
|
||||
- 'ee/spec/models/issue_spec.rb'
|
||||
- 'ee/spec/models/repository_spec.rb'
|
||||
- 'ee/spec/models/security/orchestration_policy_rule_schedule_spec.rb'
|
||||
- 'ee/spec/models/security/scan_spec.rb'
|
||||
- 'ee/spec/policies/group_policy_spec.rb'
|
||||
|
|
|
|||
|
|
@ -646,7 +646,7 @@
|
|||
{"name":"ruby-fogbugz","version":"0.3.0","platform":"ruby","checksum":"5e04cde474648f498a71cf1e1a7ab42c66b953862fbe224f793ec0a7a1d5f657"},
|
||||
{"name":"ruby-lsp","version":"0.23.20","platform":"ruby","checksum":"06956135001716b89d08385714c095e01a6b3563452e4a265781899d26fb2769"},
|
||||
{"name":"ruby-lsp-rails","version":"0.3.31","platform":"ruby","checksum":"670aed466e54b5632e4907b8dedb91d8b144917c42513e013d656af175bf8c76"},
|
||||
{"name":"ruby-lsp-rspec","version":"0.1.23","platform":"ruby","checksum":"d2a915502352e9722cd3d67e1eac6c517983ec4fe580c6de95f56f61844168d3"},
|
||||
{"name":"ruby-lsp-rspec","version":"0.1.24","platform":"ruby","checksum":"41ff78b6ddaa588d81a6c6cce7dd151ddc53246c7fe5f2fd9a94a0e30877a222"},
|
||||
{"name":"ruby-magic","version":"0.6.0","platform":"ruby","checksum":"7b2138877b7d23aff812c95564eba6473b74b815ef85beb0eb792e729a2b6101"},
|
||||
{"name":"ruby-progressbar","version":"1.11.0","platform":"ruby","checksum":"cc127db3866dc414ffccbf92928a241e585b3aa2b758a5563e74a6ee0f57d50a"},
|
||||
{"name":"ruby-saml","version":"1.18.0","platform":"ruby","checksum":"de342a55925fd5ce6114d0802651c324428c0fec26e7fe52bf3a7cfa54dbfa6d"},
|
||||
|
|
|
|||
|
|
@ -1748,7 +1748,7 @@ GEM
|
|||
sorbet-runtime (>= 0.5.10782)
|
||||
ruby-lsp-rails (0.3.31)
|
||||
ruby-lsp (>= 0.23.0, < 0.24.0)
|
||||
ruby-lsp-rspec (0.1.23)
|
||||
ruby-lsp-rspec (0.1.24)
|
||||
ruby-lsp (~> 0.23.19)
|
||||
ruby-magic (0.6.0)
|
||||
mini_portile2 (~> 2.8)
|
||||
|
|
|
|||
|
|
@ -646,7 +646,7 @@
|
|||
{"name":"ruby-fogbugz","version":"0.3.0","platform":"ruby","checksum":"5e04cde474648f498a71cf1e1a7ab42c66b953862fbe224f793ec0a7a1d5f657"},
|
||||
{"name":"ruby-lsp","version":"0.23.20","platform":"ruby","checksum":"06956135001716b89d08385714c095e01a6b3563452e4a265781899d26fb2769"},
|
||||
{"name":"ruby-lsp-rails","version":"0.3.31","platform":"ruby","checksum":"670aed466e54b5632e4907b8dedb91d8b144917c42513e013d656af175bf8c76"},
|
||||
{"name":"ruby-lsp-rspec","version":"0.1.23","platform":"ruby","checksum":"d2a915502352e9722cd3d67e1eac6c517983ec4fe580c6de95f56f61844168d3"},
|
||||
{"name":"ruby-lsp-rspec","version":"0.1.24","platform":"ruby","checksum":"41ff78b6ddaa588d81a6c6cce7dd151ddc53246c7fe5f2fd9a94a0e30877a222"},
|
||||
{"name":"ruby-magic","version":"0.6.0","platform":"ruby","checksum":"7b2138877b7d23aff812c95564eba6473b74b815ef85beb0eb792e729a2b6101"},
|
||||
{"name":"ruby-progressbar","version":"1.11.0","platform":"ruby","checksum":"cc127db3866dc414ffccbf92928a241e585b3aa2b758a5563e74a6ee0f57d50a"},
|
||||
{"name":"ruby-saml","version":"1.18.0","platform":"ruby","checksum":"de342a55925fd5ce6114d0802651c324428c0fec26e7fe52bf3a7cfa54dbfa6d"},
|
||||
|
|
|
|||
|
|
@ -1742,7 +1742,7 @@ GEM
|
|||
sorbet-runtime (>= 0.5.10782)
|
||||
ruby-lsp-rails (0.3.31)
|
||||
ruby-lsp (>= 0.23.0, < 0.24.0)
|
||||
ruby-lsp-rspec (0.1.23)
|
||||
ruby-lsp-rspec (0.1.24)
|
||||
ruby-lsp (~> 0.23.19)
|
||||
ruby-magic (0.6.0)
|
||||
mini_portile2 (~> 2.8)
|
||||
|
|
|
|||
|
|
@ -33,6 +33,7 @@ class User < ApplicationRecord
|
|||
include IgnorableColumns
|
||||
include UseSqlFunctionForPrimaryKeyLookups
|
||||
include Todoable
|
||||
include Gitlab::InternalEventsTracking
|
||||
|
||||
ignore_column :last_access_from_pipl_country_at, remove_after: '2024-11-17', remove_with: '17.7'
|
||||
ignore_column %i[role skype], remove_after: '2025-09-18', remove_with: '18.4'
|
||||
|
|
@ -2096,10 +2097,15 @@ class User < ApplicationRecord
|
|||
end
|
||||
|
||||
def ci_owned_runners
|
||||
@ci_owned_runners ||= Ci::Runner
|
||||
.from_union([ci_owned_project_runners_from_project_members,
|
||||
ci_owned_project_runners_from_group_members,
|
||||
ci_owned_group_runners])
|
||||
@ci_owned_runners ||= if Feature.enabled?(:optimize_ci_owned_project_runners_query, self)
|
||||
Ci::Runner.from_union([ci_owned_project_runners, ci_owned_group_runners])
|
||||
else
|
||||
Ci::Runner.from_union([
|
||||
ci_owned_project_runners_from_project_members,
|
||||
ci_owned_project_runners_from_group_members,
|
||||
ci_owned_group_runners
|
||||
])
|
||||
end
|
||||
end
|
||||
|
||||
def owns_runner?(runner)
|
||||
|
|
@ -2909,6 +2915,27 @@ class User < ApplicationRecord
|
|||
.where('ci_runner_projects.project_id IN (SELECT project_id FROM cte_project_ids)')
|
||||
end
|
||||
|
||||
def ci_owned_project_runners
|
||||
project_ids = project_authorizations.where(access_level: Gitlab::Access::MAINTAINER..).pluck(:project_id)
|
||||
|
||||
# track the size of project_ids to optimise this query further in future
|
||||
track_ci_owned_project_runners_query(project_ids.size)
|
||||
|
||||
# Load all project IDs upfront to handle indirect project access through group invitations
|
||||
# and avoid CTE query when filtering runners for better performance
|
||||
Ci::Runner.belonging_to_project(project_ids)
|
||||
end
|
||||
|
||||
def track_ci_owned_project_runners_query(size_of_project_ids)
|
||||
track_internal_event(
|
||||
'query_ci_owned_project_runners_with_project_ids',
|
||||
user: self,
|
||||
additional_properties: {
|
||||
value: size_of_project_ids
|
||||
}
|
||||
)
|
||||
end
|
||||
|
||||
def ci_owned_group_runners
|
||||
cte_namespace_ids = Gitlab::SQL::CTE.new(
|
||||
:cte_namespace_ids,
|
||||
|
|
|
|||
|
|
@ -31,12 +31,12 @@ module Ci
|
|||
|
||||
with_options scope: :user, score: 5
|
||||
condition(:any_maintainer_owned_groups_inheriting_shared_runners) do
|
||||
@user.owned_or_maintainers_groups.with_shared_runners_enabled.any?
|
||||
@user.owned_or_maintainers_groups.with_shared_runners_enabled.exists?
|
||||
end
|
||||
|
||||
with_options scope: :user, score: 5
|
||||
condition(:any_maintainer_projects_inheriting_shared_runners) do
|
||||
@user.authorized_projects(Gitlab::Access::MAINTAINER).with_shared_runners_enabled.any?
|
||||
@user.authorized_projects(Gitlab::Access::MAINTAINER).with_shared_runners_enabled.exists?
|
||||
end
|
||||
|
||||
with_options score: 10
|
||||
|
|
@ -67,14 +67,14 @@ module Ci
|
|||
user_group_ids = @user.owned_or_maintainers_groups.select(:id)
|
||||
|
||||
# Check for direct group relationships
|
||||
next true if user_group_ids.id_in(@subject.group_ids).any?
|
||||
next true if user_group_ids.id_in(@subject.group_ids).exists?
|
||||
|
||||
# Check for indirect group relationships
|
||||
GroupGroupLink
|
||||
.with_owner_or_maintainer_access
|
||||
.groups_accessible_via(user_group_ids)
|
||||
.id_in(@subject.group_ids)
|
||||
.any?
|
||||
.exists?
|
||||
end
|
||||
|
||||
condition(:belongs_to_multiple_projects, scope: :subject) do
|
||||
|
|
|
|||
|
|
@ -73,7 +73,8 @@ module Members
|
|||
last_group_owner = true
|
||||
|
||||
in_lock("delete_members:#{member.source.class}:#{member.source.id}", sleep_sec: 0.1.seconds) do
|
||||
break if member.source.last_owner?(member.user)
|
||||
# Explicitly bypass caching to ensure we're checking against the latest list of owners.
|
||||
break if ApplicationRecord.uncached { member.source.last_owner?(member.user) }
|
||||
|
||||
last_group_owner = false
|
||||
destroy_member(member)
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@
|
|||
.gl-flex.gl-grow
|
||||
%h4.gl-text-base.gl-leading-24.gl-m-0= _('Transfer project')
|
||||
%p.gl-text-subtle.gl-text-sm.gl-m-0
|
||||
- link = link_to('', help_page_path('user/project/settings/migrate_projects.md', anchor: 'transfer-a-project-to-another-namespace'), target: '_blank', rel: 'noopener noreferrer')
|
||||
- link = link_to('', help_page_path('user/project/working_with_projects.md', anchor: 'transfer-a-project'), target: '_blank', rel: 'noopener noreferrer')
|
||||
= safe_format(_("Transfer your project into another namespace. %{link_start}Learn more.%{link_end}"), tag_pair(link, :link_start, :link_end))
|
||||
|
||||
- c.with_body do
|
||||
|
|
|
|||
|
|
@ -0,0 +1,19 @@
|
|||
---
|
||||
description: Count of authorized projects used in user query for CI owned project runners
|
||||
internal_events: true
|
||||
status: active
|
||||
action: query_ci_owned_project_runners_with_project_ids
|
||||
identifiers:
|
||||
- user
|
||||
additional_properties:
|
||||
value:
|
||||
description: Number of project ids
|
||||
product_group: runner
|
||||
product_categories:
|
||||
- fleet_visibility
|
||||
milestone: '18.2'
|
||||
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/194442
|
||||
tiers:
|
||||
- free
|
||||
- premium
|
||||
- ultimate
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
---
|
||||
name: optimize_ci_owned_project_runners_query
|
||||
description:
|
||||
feature_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/464475
|
||||
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/194442
|
||||
rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/551320
|
||||
milestone: '18.2'
|
||||
group: group::runner
|
||||
type: gitlab_com_derisk
|
||||
default_enabled: false
|
||||
|
|
@ -29,6 +29,8 @@
|
|||
- 1
|
||||
- - admin_emails
|
||||
- 1
|
||||
- - ai_active_context_code_process_pending_enabled_namespace_event
|
||||
- 1
|
||||
- - ai_active_context_code_repository_index
|
||||
- 1
|
||||
- - ai_active_context_code_saas_initial_indexing_event
|
||||
|
|
@ -37,6 +39,8 @@
|
|||
- 1
|
||||
- - ai_repository_xray_scan_dependencies
|
||||
- 1
|
||||
- - analytics_ai_usage_events_backfill
|
||||
- 1
|
||||
- - analytics_code_review_metrics
|
||||
- 1
|
||||
- - analytics_code_suggestions_events_backfill
|
||||
|
|
|
|||
|
|
@ -5,4 +5,4 @@ feature_category: source_code_management
|
|||
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/180440
|
||||
milestone: '17.9'
|
||||
queued_migration_version: 20250205200247
|
||||
finalized_by: # version of the migration that finalized this BBM
|
||||
finalized_by: '20250623175909'
|
||||
|
|
|
|||
|
|
@ -5,4 +5,4 @@ feature_category: source_code_management
|
|||
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/180441
|
||||
milestone: '17.9'
|
||||
queued_migration_version: 20250205200743
|
||||
finalized_by: # version of the migration that finalized this BBM
|
||||
finalized_by: '20250623204353'
|
||||
|
|
|
|||
|
|
@ -0,0 +1,9 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class AddEnvironmentToDuoWorkflowsWorkflows < Gitlab::Database::Migration[2.3]
|
||||
milestone '18.2'
|
||||
|
||||
def change
|
||||
add_column :duo_workflows_workflows, :environment, :integer, limit: 2
|
||||
end
|
||||
end
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class FinalizeBackfillRequiredCodeOwnersSectionsProtectedBranchNamespaceId < Gitlab::Database::Migration[2.3]
|
||||
milestone '18.2'
|
||||
disable_ddl_transaction!
|
||||
|
||||
restrict_gitlab_migration gitlab_schema: :gitlab_main_cell
|
||||
|
||||
def up
|
||||
ensure_batched_background_migration_is_finished(
|
||||
job_class_name: 'BackfillRequiredCodeOwnersSectionsProtectedBranchNamespaceId',
|
||||
table_name: :required_code_owners_sections,
|
||||
column_name: :id,
|
||||
job_arguments: [:protected_branch_namespace_id, :protected_branches, :namespace_id, :protected_branch_id],
|
||||
finalize: true
|
||||
)
|
||||
end
|
||||
|
||||
def down; end
|
||||
end
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class FinalizeBackfillSnippetRepositoryStorageMovesSnippetProjectId < Gitlab::Database::Migration[2.3]
|
||||
milestone '18.2'
|
||||
disable_ddl_transaction!
|
||||
|
||||
restrict_gitlab_migration gitlab_schema: :gitlab_main_cell
|
||||
|
||||
def up
|
||||
ensure_batched_background_migration_is_finished(
|
||||
job_class_name: 'BackfillSnippetRepositoryStorageMovesSnippetProjectId',
|
||||
table_name: :snippet_repository_storage_moves,
|
||||
column_name: :id,
|
||||
job_arguments: [:snippet_project_id, :snippets, :project_id, :snippet_id],
|
||||
finalize: true
|
||||
)
|
||||
end
|
||||
|
||||
def down; end
|
||||
end
|
||||
|
|
@ -0,0 +1 @@
|
|||
fec0bd7e75bd00e71ee6911ab37fdeb2fc5cfe269857003fb556a39e0f2936bc
|
||||
|
|
@ -0,0 +1 @@
|
|||
f419828c4f08c737c8c369c29c4144912b3656ffe0ce64391f1b9425c6004022
|
||||
|
|
@ -0,0 +1 @@
|
|||
84def69e669232f4bbb1ca1cdd1e46cc95b3a0200e3ca32d5e005122404f52b5
|
||||
|
|
@ -14319,6 +14319,7 @@ CREATE TABLE duo_workflows_workflows (
|
|||
allow_agent_to_request_user boolean DEFAULT true NOT NULL,
|
||||
pre_approved_agent_privileges smallint[] DEFAULT '{1,2}'::smallint[] NOT NULL,
|
||||
image text,
|
||||
environment smallint,
|
||||
CONSTRAINT check_30ca07a4ef CHECK ((char_length(goal) <= 16384)),
|
||||
CONSTRAINT check_3a9162f1ae CHECK ((char_length(image) <= 2048)),
|
||||
CONSTRAINT check_ec723e2a1a CHECK ((char_length(workflow_definition) <= 255))
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ title: Set up Geo for two single-node sites
|
|||
|
||||
{{< /details >}}
|
||||
|
||||
The following guide provides concise instructions on how to deploy GitLab Geo for a two single-node site installation using two Linux package instances with no external services set up.
|
||||
The following guide provides concise instructions on how to deploy GitLab Geo for a two single-node site installation using two Linux package instances with no external services set up. This guide is also applicable to installations based on [Docker](../../../install/docker/_index.md).
|
||||
|
||||
Prerequisites:
|
||||
|
||||
|
|
@ -33,6 +33,16 @@ Prerequisites:
|
|||
|
||||
### Configure the primary site
|
||||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
For Docker-based installations:
|
||||
|
||||
Either apply the settings mentioned below directly to the GitLab container's `/etc/gitlab/gitlab.rb` file, or add them to the `GITLAB_OMNIBUS_CONFIG` environment variable in its [Docker Compose](../../../install/docker/installation.md#install-gitlab-by-using-docker-compose) file.
|
||||
|
||||
When using [Docker Compose](../../../install/docker/installation.md#install-gitlab-by-using-docker-compose), use `docker-compose -f <docker-compose-file-name>.yml up` instead of `gitlab-ctl reconfigure` to apply configuration changes.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
1. SSH into your GitLab primary site and sign in as root:
|
||||
|
||||
```shell
|
||||
|
|
@ -298,15 +308,36 @@ Prerequisites:
|
|||
1. Test that the `gitlab-psql` user can connect to the primary site database.
|
||||
The default Linux package name is `gitlabhq_production`:
|
||||
|
||||
```shell
|
||||
sudo \
|
||||
-u gitlab-psql /opt/gitlab/embedded/bin/psql \
|
||||
--list \
|
||||
-U gitlab_replicator \
|
||||
-d "dbname=gitlabhq_production sslmode=verify-ca" \
|
||||
-W \
|
||||
-h <primary_site_ip>
|
||||
```
|
||||
{{< tabs >}}
|
||||
|
||||
{{< tab title="Linux package" >}}
|
||||
|
||||
```shell
|
||||
sudo \
|
||||
-u gitlab-psql /opt/gitlab/embedded/bin/psql \
|
||||
--list \
|
||||
-U gitlab_replicator \
|
||||
-d "dbname=gitlabhq_production sslmode=verify-ca" \
|
||||
-W \
|
||||
-h <primary_site_ip>
|
||||
```
|
||||
|
||||
{{< /tab >}}
|
||||
|
||||
{{< tab title="Docker" >}}
|
||||
|
||||
```shell
|
||||
docker exec -it <container_name> su - gitlab-psql -c '/opt/gitlab/embedded/bin/psql \
|
||||
--list \
|
||||
-U gitlab_replicator \
|
||||
-d "dbname=gitlabhq_production sslmode=verify-ca" \
|
||||
-W \
|
||||
-h <primary_site_ip>'
|
||||
```
|
||||
|
||||
{{< /tab >}}
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
When prompted, enter the plaintext password you set for the `gitlab_replicator` user.
|
||||
If all worked correctly, you should see the list of the primary site databases.
|
||||
|
|
|
|||
|
|
@ -23,7 +23,8 @@ The package registry supports the following formats:
|
|||
| Package type | GitLab version |
|
||||
|--------------------------------------------------------------------|----------------|
|
||||
| [Composer](../../user/packages/composer_repository/_index.md) | 13.2+ |
|
||||
| [Conan](../../user/packages/conan_repository/_index.md) | 12.6+ |
|
||||
| [Conan 1](../../user/packages/conan_1_repository/_index.md) | 12.6+ |
|
||||
| [Conan 2](../../user/packages/conan_2_repository/_index.md) | 18.1+ |
|
||||
| [Go](../../user/packages/go_proxy/_index.md) | 13.1+ |
|
||||
| [Maven](../../user/packages/maven_repository/_index.md) | 11.3+ |
|
||||
| [npm](../../user/packages/npm_registry/_index.md) | 11.7+ |
|
||||
|
|
|
|||
|
|
@ -339,7 +339,7 @@ this setting needs to be configured on the main GitLab server.
|
|||
|
||||
If the wildcard DNS [prerequisite](_index.md#prerequisites) can't be met, you can still use GitLab Pages in a limited fashion:
|
||||
|
||||
1. [Move](../../user/project/settings/migrate_projects.md#transfer-a-project-to-another-namespace)
|
||||
1. [Move](../../user/project/working_with_projects.md#transfer-a-project)
|
||||
all projects you need to use Pages with into a single group namespace, for example `pages`.
|
||||
1. Configure a [DNS entry](_index.md#dns-configuration) without the `*.`-wildcard, for example `pages.example.io`.
|
||||
1. Configure `pages_external_url http://example.io/` in your `gitlab.rb` file.
|
||||
|
|
|
|||
|
|
@ -680,6 +680,7 @@ four standard [pagination arguments](#pagination-arguments):
|
|||
|
||||
| Name | Type | Description |
|
||||
| ---- | ---- | ----------- |
|
||||
| <a id="queryduoworkflowworkflowsenvironment"></a>`environment` | [`WorkflowEnvironment`](#workflowenvironment) | Environment, e.g., ide or web. |
|
||||
| <a id="queryduoworkflowworkflowsprojectpath"></a>`projectPath` | [`ID`](#id) | Full path of the project containing the workflows. |
|
||||
| <a id="queryduoworkflowworkflowssort"></a>`sort` | [`Sort`](#sort) | Sort workflows by the criteria. |
|
||||
| <a id="queryduoworkflowworkflowstype"></a>`type` | [`String`](#string) | Type of workflow to filter by (e.g., software_development). |
|
||||
|
|
@ -27030,6 +27031,7 @@ A Duo Workflow.
|
|||
| Name | Type | Description |
|
||||
| ---- | ---- | ----------- |
|
||||
| <a id="duoworkflowcreatedat"></a>`createdAt` | [`Time!`](#time) | Timestamp of when the workflow was created. |
|
||||
| <a id="duoworkflowenvironment"></a>`environment` | [`WorkflowEnvironment`](#workflowenvironment) | Environment, e.g., ide or web. |
|
||||
| <a id="duoworkflowgoal"></a>`goal` | [`String`](#string) | Goal of the workflow. |
|
||||
| <a id="duoworkflowhumanstatus"></a>`humanStatus` | [`String!`](#string) | Human-readable status of the workflow. |
|
||||
| <a id="duoworkflowid"></a>`id` | [`ID!`](#id) | ID of the workflow. |
|
||||
|
|
@ -47806,6 +47808,15 @@ Type of a work item widget.
|
|||
| <a id="workitemwidgettypevulnerabilities"></a>`VULNERABILITIES` | Vulnerabilities widget. |
|
||||
| <a id="workitemwidgettypeweight"></a>`WEIGHT` | Weight widget. |
|
||||
|
||||
### `WorkflowEnvironment`
|
||||
|
||||
The environment of a workflow.
|
||||
|
||||
| Value | Description |
|
||||
| ----- | ----------- |
|
||||
| <a id="workflowenvironmentide"></a>`IDE` | Ide environment. |
|
||||
| <a id="workflowenvironmentweb"></a>`WEB` | Web environment. |
|
||||
|
||||
### `WorkspaceVariableInputType`
|
||||
|
||||
Enum for the type of the variable to be injected in a workspace.
|
||||
|
|
|
|||
|
|
@ -31,11 +31,12 @@ administrator, this endpoint returns all namespaces in the instance.
|
|||
GET /namespaces
|
||||
```
|
||||
|
||||
| Attribute | Type | Required | Description |
|
||||
| ---------------- | ------- | -------- | ----------- |
|
||||
| `search` | string | no | Returns only namespaces that contain the specified value in their name or path. |
|
||||
| `owned_only` | boolean | no | If `true`, only returns namespaces by the current user. |
|
||||
| `top_level_only` | boolean | no | In GitLab 16.8 and later, if `true`, only returns top-level namespaces. |
|
||||
| Attribute | Type | Required | Description |
|
||||
|--------------------|---------|----------|-----------------------------------------------------------------------------------------|
|
||||
| `search` | string | no | Returns only namespaces that contain the specified value in their name or path. |
|
||||
| `owned_only` | boolean | no | If `true`, only returns namespaces by the current user. |
|
||||
| `top_level_only` | boolean | no | In GitLab 16.8 and later, if `true`, only returns top-level namespaces. |
|
||||
| `full_path_search` | boolean | no | If `true`, the `search` parameter is matched against the full path of the namespaces. |
|
||||
|
||||
Example request:
|
||||
|
||||
|
|
|
|||
|
|
@ -41978,6 +41978,13 @@ paths:
|
|||
type: boolean
|
||||
default: false
|
||||
required: false
|
||||
- in: query
|
||||
name: full_path_search
|
||||
description: If `true`, the `search` parameter is matched against the full
|
||||
path of the namespaces
|
||||
type: boolean
|
||||
default: false
|
||||
required: false
|
||||
- in: query
|
||||
name: page
|
||||
description: Current page number
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ For Conan v2 operations, see [Conan v2 API](conan_v2.md).
|
|||
|
||||
Use this API to interact with the Conan v1 package manager. These endpoints work for both
|
||||
projects and instances. For more information,
|
||||
see [Conan packages in the package registry](../../user/packages/conan_repository/_index.md).
|
||||
see [Conan packages in the package registry](../../user/packages/conan_1_repository/_index.md).
|
||||
|
||||
Generally, these endpoints are used by the [Conan 1 package manager client](https://docs.conan.io/en/latest/)
|
||||
and are not meant for manual consumption.
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ For Conan v1 operations, see [Conan v1 API](conan_v1.md).
|
|||
|
||||
{{< /alert >}}
|
||||
|
||||
Use this API to interact with the Conan v2 package manager. For more information, see [Conan packages in the package registry](../../user/packages/conan_repository/_index.md) or [Conan 2 package manager client](https://docs.conan.io/2/index.html).
|
||||
Use this API to interact with the Conan v2 package manager. For more information, see [Conan packages in the package registry](../../user/packages/conan_2_repository/_index.md) or [Conan 2 package manager client](https://docs.conan.io/2/index.html).
|
||||
|
||||
Generally, these endpoints are used by the [Conan 2 package manager client](https://docs.conan.io/2/index.html)
|
||||
and are not meant for manual consumption.
|
||||
|
|
|
|||
|
|
@ -2206,7 +2206,7 @@ Supported attributes:
|
|||
Transfer a project to a new namespace.
|
||||
|
||||
For information on prerequisites for transferring a project, see
|
||||
[Transfer a project to another namespace](../user/project/settings/migrate_projects.md#transfer-a-project-to-another-namespace).
|
||||
[Transfer a project to another namespace](../user/project/working_with_projects.md#transfer-a-project).
|
||||
|
||||
```plaintext
|
||||
PUT /projects/:id/transfer
|
||||
|
|
|
|||
|
|
@ -22,6 +22,13 @@ For a step-by-step guide for first-time contributors, see [Tutorial: Make a GitL
|
|||
1. Make changes and open a merge request.
|
||||
1. Your merge request is triaged, reviewed, and can then be incorporated into the product.
|
||||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
All contributions must be submitted in English. GitLab engineering work is done in English,
|
||||
and merge requests and issues in other languages cannot be reviewed or accepted.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
## GitLab technologies
|
||||
|
||||
[GitLab](https://gitlab.com/gitlab-org/gitlab) is a [Ruby on Rails](https://rubyonrails.org/) application.
|
||||
|
|
|
|||
|
|
@ -55,6 +55,20 @@ When you find an issue you'd like to work on:
|
|||
You can try installing and running the [Vale linting tool](testing/vale.md)
|
||||
and fixing the resulting issues.
|
||||
|
||||
### Translated documentation
|
||||
|
||||
To make GitLab documentation easier to use around the world, we plan to have product documentation
|
||||
translated and published in other languages.
|
||||
|
||||
The [file structure](site_architecture/_index.md#documentation-in-other-languages)
|
||||
and initial translations have been created, but this project is not complete.
|
||||
|
||||
After the official public release of the translated documentation, we will share details
|
||||
on how to help us improve our translations. But while this work is in progress,
|
||||
we cannot accept contributions to any translations of product documentation.
|
||||
|
||||
Additionally, only localization team members can change localization-related files.
|
||||
|
||||
## Ask for help
|
||||
|
||||
Ask for help from the Technical Writing team if you:
|
||||
|
|
|
|||
|
|
@ -63,6 +63,25 @@ Then you can use one of these approaches:
|
|||
We do not encourage the use of [pages with lists of links](../topic_types/_index.md#pages-and-topics-to-avoid),
|
||||
so only use this option if the recommended options are not feasible.
|
||||
|
||||
## Documentation in other languages
|
||||
|
||||
Translations of GitLab documentation are done through a semi-autonomous process.
|
||||
The [English files](#source-files) are the canonical source files, and the translations
|
||||
are in language-specific subdirectories under `doc-locale` or similar. For example, Japanese translations
|
||||
are in `/doc-locale/ja-jp/`.
|
||||
|
||||
| Project | Path |
|
||||
|-----------------|------|
|
||||
| GitLab | [`/doc-locale`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/doc-locale) |
|
||||
| GitLab Runner | [`/docs-locale`](https://gitlab.com/gitlab-org/gitlab-runner/-/tree/main/docs-locale) |
|
||||
| Omnibus GitLab | [`/doc-locale`](https://gitlab.com/gitlab-org/omnibus-gitlab/tree/master/doc-locale) |
|
||||
| Charts | [`/doc-locale`](https://gitlab.com/gitlab-org/charts/gitlab/tree/master/doc-locale) |
|
||||
| GitLab Operator | [`/doc-locale`](https://gitlab.com/gitlab-org/cloud-native/gitlab-operator/-/tree/master/doc-locale) |
|
||||
|
||||
Development documentation under `doc/development` or similar is not translated.
|
||||
|
||||
You can contribute to the English source files only. The translated files are updated by automation.
|
||||
|
||||
## Monthly release process (versions)
|
||||
|
||||
The docs website supports versions and each month we add the latest one to the list.
|
||||
|
|
|
|||
|
|
@ -121,7 +121,8 @@ listed here that also do not work properly in FIPS mode:
|
|||
|
||||
Additionally, these package repositories are disabled in FIPS mode:
|
||||
|
||||
- [Conan package repository](../user/packages/conan_repository/_index.md).
|
||||
- [Conan 1 package repository](../user/packages/conan_1_repository/_index.md).
|
||||
- [Conan 2 package repository](../user/packages/conan_2_repository/_index.md).
|
||||
- [Debian package repository](../user/packages/debian_repository/_index.md).
|
||||
|
||||
### Development guidelines
|
||||
|
|
|
|||
|
|
@ -75,8 +75,8 @@ Composer package naming scope is Instance Level.
|
|||
|
||||
To avoid name conflict for instance-level endpoints you must define a package naming convention
|
||||
that gives a way to identify the project that the package belongs to. This generally involves using the project
|
||||
ID or full project path in the package name. See
|
||||
[Conan's naming convention](../../user/packages/conan_repository/_index.md#package-recipe-naming-convention-for-instance-remotes) as an example.
|
||||
ID or full project path in the package name. For more information with an example, see
|
||||
[Package recipe naming convention for instance remotes](../../user/packages/conan_1_repository/_index.md#package-recipe-naming-convention-for-instance-remotes).
|
||||
|
||||
For group and project-level endpoints, naming can be less constrained and it is up to the group and project
|
||||
members to be certain that there is no conflict between two package names. However, the system should prevent
|
||||
|
|
|
|||
|
|
@ -203,7 +203,7 @@ can install it with:
|
|||
sudo apt-get install -y postfix
|
||||
```
|
||||
|
||||
Then select 'Internet Site' and press <kbd>Enter</kbd> to confirm the hostname.
|
||||
Then select `Internet Site` and press <kbd>Enter</kbd> to confirm the hostname.
|
||||
|
||||
### ExifTool
|
||||
|
||||
|
|
@ -1226,7 +1226,7 @@ sudo -u git -H gem install google-protobuf --version 3.2.0 --platform ruby
|
|||
```
|
||||
|
||||
Finally, you can test whether `google-protobuf` loads correctly. The
|
||||
following should print 'OK'.
|
||||
following should print `OK`.
|
||||
|
||||
```shell
|
||||
sudo -u git -H bundle exec ruby -rgoogle/protobuf -e 'puts :OK'
|
||||
|
|
|
|||
|
|
@ -77,7 +77,7 @@ project.
|
|||
{{< alert type="note" >}}
|
||||
|
||||
For more information about these migration steps,
|
||||
see [Transferring your project into another namespace](../../user/project/settings/migrate_projects.md#transfer-a-project-to-another-namespace).
|
||||
see [Transferring your project into another namespace](../../user/project/working_with_projects.md#transfer-a-project).
|
||||
A migration might result in follow-up work to update the project path in
|
||||
your related resources and tools, such as websites and package managers.
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,171 @@
|
|||
---
|
||||
stage: Security Risk Management
|
||||
group: Security Policies
|
||||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
|
||||
title: "Tutorial: Set up a pipeline execution policy"
|
||||
---
|
||||
|
||||
{{< details >}}
|
||||
|
||||
- Tier: Ultimate
|
||||
- Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
|
||||
|
||||
{{< /details >}}
|
||||
|
||||
This tutorial shows you how to create and configure a [pipeline execution policy](../../user/application_security/policies/pipeline_execution_policies.md) with `inject_policy` strategy. You can use these policies to ensure that required pipelines are always run in projects that the policy is linked to.
|
||||
|
||||
In this tutorial, you can create a pipeline execution policy, link it to a test project, and verify that the pipeline executes.
|
||||
|
||||
To set up a pipeline execution policy, you:
|
||||
|
||||
1. [Create a test project](#create-a-test-project).
|
||||
1. [Create a CI/CD configuration file](#create-a-cicd-configuration-file).
|
||||
1. [Add a pipeline execution policy](#add-a-pipeline-execution-policy).
|
||||
1. [Test the pipeline execution policy](#test-the-pipeline-execution-policy).
|
||||
|
||||
## Before you begin
|
||||
|
||||
To complete this tutorial, you need:
|
||||
|
||||
- Permissions to create projects in an existing group.
|
||||
- Permissions to create and link to security policies.
|
||||
|
||||
## Create a test project
|
||||
|
||||
To begin, create a test project to apply your pipeline execution policy to:
|
||||
|
||||
1. On the left sidebar, select **Search or go to** and find your group.
|
||||
1. Select **New project**.
|
||||
1. Select **Create blank project**.
|
||||
1. Complete the fields.
|
||||
- **Project name**: `my-pipeline-execution-policy`.
|
||||
- Select the **Enable Static Application Security Testing (SAST)** checkbox.
|
||||
1. Select **Create project**.
|
||||
|
||||
## Create a CI/CD configuration file
|
||||
|
||||
Next, create the CI/CD configuration file that you want your pipeline execution policy to enforce:
|
||||
|
||||
1. Select **Code** > **Repository**.
|
||||
1. From the **Add** (+) dropdown list, select **New file**.
|
||||
1. In the **Filename** field, enter `pipeline-config.yml`.
|
||||
1. In the file's content, copy the following:
|
||||
|
||||
```yaml
|
||||
# This file defines the CI/CD jobs that will be enforced by the pipeline execution policy
|
||||
enforced-security-scan:
|
||||
stage: .pipeline-policy-pre
|
||||
script:
|
||||
- echo "Running enforced security scan from pipeline execution policy"
|
||||
- echo "This job cannot be skipped by developers"
|
||||
- echo "Checking for security vulnerabilities..."
|
||||
- echo "Security scan completed successfully"
|
||||
rules:
|
||||
- when: always
|
||||
|
||||
enforced-test-job:
|
||||
stage: test
|
||||
script:
|
||||
- echo "Running enforced test job in test stage"
|
||||
- echo "Creating test stage if it doesn't exist"
|
||||
- echo "Performing mandatory testing requirements..."
|
||||
- echo "Enforced tests completed successfully"
|
||||
rules:
|
||||
- when: always
|
||||
|
||||
enforced-compliance-check:
|
||||
stage: .pipeline-policy-post
|
||||
script:
|
||||
- echo "Running enforced compliance check"
|
||||
- echo "Verifying pipeline compliance requirements"
|
||||
- echo "Compliance check passed"
|
||||
rules:
|
||||
- when: always
|
||||
```
|
||||
|
||||
1. In the **Commit message** field, enter `Add pipeline execution policy configuration`.
|
||||
1. Select **Commit changes**.
|
||||
|
||||
## Add a pipeline execution policy
|
||||
|
||||
Next, add a pipeline execution policy to your test project:
|
||||
|
||||
1. Select **Secure > Policies**.
|
||||
1. Select **New policy**.
|
||||
1. In **Pipeline execution policy**, select **Select policy**.
|
||||
1. Complete the fields.
|
||||
- **Name**: `Enforce Security and Compliance Jobs`
|
||||
- **Description**: `Enforces required security and compliance jobs across all pipelines`
|
||||
- **Policy status**: **Enabled**
|
||||
|
||||
1. Set **Actions** to the following:
|
||||
|
||||
```plaintext
|
||||
Inject into into the .gitlab-ci.yml with the pipeline execution file from My Pipeline Execution Policy
|
||||
Filepath: [group]/my-pipeline-execution/policy/pipeline-config.yml
|
||||
```
|
||||
|
||||
1. Select **Configure with a merge request**.
|
||||
|
||||
1. Review the generated policy YAML in the merge request's **Changes** tab. The policy should look similar to:
|
||||
|
||||
```yaml
|
||||
---
|
||||
pipeline_execution_policy:
|
||||
- name: Enforce Security and Compliance Jobs
|
||||
description: Enforces required security and compliance jobs across all pipelines
|
||||
enabled: true
|
||||
pipeline_config_strategy: inject_policy
|
||||
content:
|
||||
include:
|
||||
- project: [group]/my-pipeline-execution-policy
|
||||
file: pipeline-config.yml
|
||||
skip_ci:
|
||||
- allowed: false
|
||||
```
|
||||
|
||||
1. Go to the **Overview** tab and select **Merge**. This step creates a new project called `My Pipeline Execution Policy - Security Policy Project`. Security policy projects are used to store security policies so the same policy can be enforced across multiple projects.
|
||||
|
||||
1. On the left sidebar, select **Search or go to** and find the `my-pipeline-execution-policy` project.
|
||||
|
||||
1. Select **Secure > Policies**.
|
||||
|
||||
You can see the list of policies added in the previous steps.
|
||||
|
||||
## Test the pipeline execution policy
|
||||
|
||||
Now test your pipeline execution policy by creating a merge request:
|
||||
|
||||
1. Select **Code** > **Repository**.
|
||||
1. From the **Add** (+) dropdown list, select **New file**.
|
||||
1. In the **Filename** field, enter `test-file.txt`.
|
||||
1. In the file's content, add:
|
||||
|
||||
```plaintext
|
||||
This is a test file to trigger the pipeline execution policy.
|
||||
```
|
||||
|
||||
1. In the **Commit message** field, enter `Add test file to trigger pipeline`.
|
||||
1. In the **Target Branch** field, enter `test-policy-branch`.
|
||||
1. Select **Commit changes**.
|
||||
1. When the merge request page opens, select **Create merge request**.
|
||||
|
||||
Wait for the pipeline to complete. This could take a few minutes.
|
||||
|
||||
1. In the merge request, select the **Pipelines** tab and select the created pipeline.
|
||||
|
||||
You should see the enforced jobs running:
|
||||
- `enforced-security-scan` in the `.pipeline-policy-pre` stage (runs first)
|
||||
- `enforced-test-job` in the `test` stage (injected by the policy)
|
||||
- `enforced-compliance-check` in the `.pipeline-policy-post` stage (runs last)
|
||||
|
||||
1. Select the `enforced-security-scan` job to view its logs and confirm it executed the security scan as defined in the policy.
|
||||
|
||||
The pipeline execution policy successfully enforced the required jobs, ensuring they run regardless of what the developer includes in their project's `.gitlab-ci.yml` file.
|
||||
|
||||
You now know how to set up and use pipeline execution policies to enforce the use of required CI/CD jobs across projects in your organization!
|
||||
|
||||
## Next steps
|
||||
|
||||
- Learn more about [pipeline execution policy configuration strategies](../../user/application_security/policies/pipeline_execution_policies.md#pipeline-configuration-strategies).
|
||||
- Explore [advanced pipeline execution policy examples](../../user/application_security/policies/pipeline_execution_policies.md#examples).
|
||||
|
|
@ -23,10 +23,9 @@ To set up a merge request approval policy:
|
|||
|
||||
## Before you begin
|
||||
|
||||
The namespace used for this tutorial must:
|
||||
|
||||
- Contain a minimum of three users, including your own. If you don't have two other users, you must first
|
||||
create them. For details, see [Creating users](../../user/profile/account/create_accounts.md).
|
||||
- The namespace you use for this tutorial must contain a minimum of three users, including your own. If you don't have two other
|
||||
users, you must first create them. For details, see [Creating users](../../user/profile/account/create_accounts.md).
|
||||
- You need permission to create new projects in an existing group.
|
||||
|
||||
## Create a test project
|
||||
|
||||
|
|
|
|||
|
|
@ -118,7 +118,7 @@ see [Packaged PostgreSQL deployed in an HA/Geo Cluster](https://docs.gitlab.com/
|
|||
### Geo installations
|
||||
|
||||
- Due to a bug introduced GitLab 16.5 and fixed in 17.0, [GitLab Pages](../../administration/pages/_index.md) deployment files are being orphaned on secondary Geo sites. If Pages deployments are stored locally, then this can lead to zero remaining storage and subsequently data loss in the event of a failover.
|
||||
See details of the problem and workaround in issue [#457159](https://gitlab.com/gitlab-org/gitlab/-/issues/457159).
|
||||
See details of the problem and workaround in [issue 457159](https://gitlab.com/gitlab-org/gitlab/-/issues/457159).
|
||||
|
||||
**Affected releases**:
|
||||
|
||||
|
|
@ -207,7 +207,7 @@ For more information on the changes introduced between version 2.1.0 and version
|
|||
### Geo installations
|
||||
|
||||
- Due to a bug introduced GitLab 16.5 and fixed in 17.0, [GitLab Pages](../../administration/pages/_index.md) deployment files are being orphaned on secondary Geo sites. If Pages deployments are stored locally, then this can lead to zero remaining storage and subsequently data loss in the event of a failover.
|
||||
See details of the problem and workaround in issue [#457159](https://gitlab.com/gitlab-org/gitlab/-/issues/457159).
|
||||
See details of the problem and workaround in [issue 457159](https://gitlab.com/gitlab-org/gitlab/-/issues/457159).
|
||||
|
||||
**Affected releases**:
|
||||
|
||||
|
|
@ -243,7 +243,7 @@ planned for release in 16.9.1.
|
|||
| All | All | 16.10.2 |
|
||||
|
||||
- Due to a bug introduced GitLab 16.5, [personal snippets](../../user/snippets.md) are not being replicated to secondary Geo sites. This can lead to loss of personal snippet data in the event of a Geo failover.
|
||||
See details of the problem and workaround in issue [#439933](https://gitlab.com/gitlab-org/gitlab/-/issues/439933).
|
||||
See details of the problem and workaround in [issue 439933](https://gitlab.com/gitlab-org/gitlab/-/issues/439933).
|
||||
|
||||
**Affected releases**:
|
||||
|
||||
|
|
@ -265,7 +265,7 @@ planned for release in 16.9.1.
|
|||
| 16.9 | 16.9.0 - 16.9.1 | 16.9.2 |
|
||||
|
||||
- Due to a bug introduced GitLab 16.5 and fixed in 17.0, [GitLab Pages](../../administration/pages/_index.md) deployment files are being orphaned on secondary Geo sites. If Pages deployments are stored locally, then this can lead to zero remaining storage and subsequently data loss in the event of a failover.
|
||||
See details of the problem and workaround in issue [#457159](https://gitlab.com/gitlab-org/gitlab/-/issues/457159).
|
||||
See details of the problem and workaround in [issue 457159](https://gitlab.com/gitlab-org/gitlab/-/issues/457159).
|
||||
|
||||
**Affected releases**:
|
||||
|
||||
|
|
@ -321,7 +321,7 @@ planned for release in 16.9.1.
|
|||
- Upgrade all existing sites to GitLab 16.8.2 or later and PostgreSQL 14 before you add the new Geo secondary site to the deployment.
|
||||
|
||||
- Due to a bug introduced GitLab 16.5, [personal snippets](../../user/snippets.md) are not being replicated to secondary Geo sites. This can lead to loss of personal snippet data in the event of a Geo failover.
|
||||
See details of the problem and workaround in issue [#439933](https://gitlab.com/gitlab-org/gitlab/-/issues/439933).
|
||||
See details of the problem and workaround in [issue 439933](https://gitlab.com/gitlab-org/gitlab/-/issues/439933).
|
||||
|
||||
**Affected releases**:
|
||||
|
||||
|
|
@ -343,7 +343,7 @@ planned for release in 16.9.1.
|
|||
| 16.9 | 16.9.0 - 16.9.1 | 16.9.2 |
|
||||
|
||||
- Due to a bug introduced GitLab 16.5 and fixed in 17.0, [GitLab Pages](../../administration/pages/_index.md) deployment files are being orphaned on secondary Geo sites. If Pages deployments are stored locally, then this can lead to zero remaining storage and subsequently data loss in the event of a failover.
|
||||
See details of the problem and workaround in issue [#457159](https://gitlab.com/gitlab-org/gitlab/-/issues/457159).
|
||||
See details of the problem and workaround in [issue 457159](https://gitlab.com/gitlab-org/gitlab/-/issues/457159).
|
||||
|
||||
**Affected releases**:
|
||||
|
||||
|
|
@ -420,7 +420,7 @@ Specific information applies to Linux package installations:
|
|||
| 16.7 | 16.7.0 - 16.7.3 | 16.7.4 |
|
||||
|
||||
- Due to a bug introduced GitLab 16.5, [personal snippets](../../user/snippets.md) are not being replicated to secondary Geo sites. This can lead to loss of personal snippet data in the event of a Geo failover.
|
||||
See details of the problem and workaround in issue [#439933](https://gitlab.com/gitlab-org/gitlab/-/issues/439933).
|
||||
See details of the problem and workaround in [issue 439933](https://gitlab.com/gitlab-org/gitlab/-/issues/439933).
|
||||
|
||||
**Affected releases**:
|
||||
|
||||
|
|
@ -433,7 +433,7 @@ Specific information applies to Linux package installations:
|
|||
| 16.9 | 16.9.0 - 16.9.1 | 16.9.2 |
|
||||
|
||||
- Due to a bug introduced GitLab 16.5 and fixed in 17.0, [GitLab Pages](../../administration/pages/_index.md) deployment files are being orphaned on secondary Geo sites. If Pages deployments are stored locally, then this can lead to zero remaining storage and subsequently data loss in the event of a failover.
|
||||
See details of the problem and workaround in issue [#457159](https://gitlab.com/gitlab-org/gitlab/-/issues/457159).
|
||||
See details of the problem and workaround in [issue 457159](https://gitlab.com/gitlab-org/gitlab/-/issues/457159).
|
||||
|
||||
**Affected releases**:
|
||||
|
||||
|
|
@ -509,7 +509,7 @@ Specific information applies to Linux package installations:
|
|||
| 16.7 | 16.7.0 - 16.7.3 | 16.7.4 |
|
||||
|
||||
- Due to a bug introduced GitLab 16.5, [personal snippets](../../user/snippets.md) are not being replicated to secondary Geo sites. This can lead to loss of personal snippet data in the event of a Geo failover.
|
||||
See details of the problem and workaround in issue [#439933](https://gitlab.com/gitlab-org/gitlab/-/issues/439933).
|
||||
See details of the problem and workaround in [issue 439933](https://gitlab.com/gitlab-org/gitlab/-/issues/439933).
|
||||
|
||||
**Affected releases**:
|
||||
|
||||
|
|
@ -522,7 +522,7 @@ Specific information applies to Linux package installations:
|
|||
| 16.9 | 16.9.0 - 16.9.1 | 16.9.2 |
|
||||
|
||||
- Due to a bug introduced GitLab 16.5 and fixed in 17.0, [GitLab Pages](../../administration/pages/_index.md) deployment files are being orphaned on secondary Geo sites. If Pages deployments are stored locally, then this can lead to zero remaining storage and subsequently data loss in the event of a failover.
|
||||
See details of the problem and workaround in issue [#457159](https://gitlab.com/gitlab-org/gitlab/-/issues/457159).
|
||||
See details of the problem and workaround in [issue 457159](https://gitlab.com/gitlab-org/gitlab/-/issues/457159).
|
||||
|
||||
**Affected releases**:
|
||||
|
||||
|
|
@ -642,7 +642,7 @@ Specific information applies to installations using Geo:
|
|||
|
||||
- After [Group Wiki](../../user/project/wiki/group.md) verification was added in GitLab 16.3, missing Group Wiki repositories are being incorrectly flagged as failing verification. This issue is not a result of an actual replication/verification failure but an invalid internal state for these missing repositories inside Geo and results in errors in the logs and the verification progress reporting a failed state for these Group Wiki repositories.
|
||||
|
||||
See details of the problem and workaround in issue [#426571](https://gitlab.com/gitlab-org/gitlab/-/issues/426571)
|
||||
See details of the problem and workaround in [issue 426571](https://gitlab.com/gitlab-org/gitlab/-/issues/426571)
|
||||
|
||||
**Affected releases**:
|
||||
|
||||
|
|
@ -665,7 +665,7 @@ Specific information applies to installations using Geo:
|
|||
| 16.7 | 16.7.0 - 16.7.3 | 16.7.4 |
|
||||
|
||||
- Due to a bug introduced GitLab 16.5, [personal snippets](../../user/snippets.md) are not being replicated to secondary Geo sites. This can lead to loss of personal snippet data in the event of a Geo failover.
|
||||
See details of the problem and workaround in issue [#439933](https://gitlab.com/gitlab-org/gitlab/-/issues/439933).
|
||||
See details of the problem and workaround in [issue 439933](https://gitlab.com/gitlab-org/gitlab/-/issues/439933).
|
||||
|
||||
**Affected releases**:
|
||||
|
||||
|
|
@ -678,7 +678,7 @@ Specific information applies to installations using Geo:
|
|||
| 16.9 | 16.9.0 - 16.9.1 | 16.9.2 |
|
||||
|
||||
- Due to a bug introduced GitLab 16.5 and fixed in 17.0, [GitLab Pages](../../administration/pages/_index.md) deployment files are being orphaned on secondary Geo sites. If Pages deployments are stored locally, then this can lead to zero remaining storage and subsequently data loss in the event of a failover.
|
||||
See details of the problem and workaround in issue [#457159](https://gitlab.com/gitlab-org/gitlab/-/issues/457159).
|
||||
See details of the problem and workaround in [issue 457159](https://gitlab.com/gitlab-org/gitlab/-/issues/457159).
|
||||
|
||||
**Affected releases**:
|
||||
|
||||
|
|
@ -838,7 +838,7 @@ Specific information applies to installations using Geo:
|
|||
|
||||
- After [Group Wiki](../../user/project/wiki/group.md) verification was added in GitLab 16.3, missing Group Wiki repositories are being incorrectly flagged as failing verification. This issue is not a result of an actual replication/verification failure but an invalid internal state for these missing repositories inside Geo and results in errors in the logs and the verification progress reporting a failed state for these Group Wiki repositories.
|
||||
|
||||
See details of the problem and workaround in issue [#426571](https://gitlab.com/gitlab-org/gitlab/-/issues/426571)
|
||||
See details of the problem and workaround in [issue 426571](https://gitlab.com/gitlab-org/gitlab/-/issues/426571)
|
||||
|
||||
**Affected releases**:
|
||||
|
||||
|
|
@ -987,7 +987,7 @@ Specific information applies to installations using Geo:
|
|||
|
||||
- After [Group Wiki](../../user/project/wiki/group.md) verification was added in GitLab 16.3, missing Group Wiki repositories are being incorrectly flagged as failing verification. This issue is not a result of an actual replication/verification failure but an invalid internal state for these missing repositories inside Geo and results in errors in the logs and the verification progress reporting a failed state for these Group Wiki repositories.
|
||||
|
||||
See details of the problem and workaround in issue [#426571](https://gitlab.com/gitlab-org/gitlab/-/issues/426571)
|
||||
See details of the problem and workaround in [issue 426571](https://gitlab.com/gitlab-org/gitlab/-/issues/426571)
|
||||
|
||||
**Affected releases**:
|
||||
|
||||
|
|
|
|||
|
|
@ -126,7 +126,7 @@ When transferring groups, note:
|
|||
- Transfers fail if the group is a top-level group and [npm packages](../packages/npm_registry/_index.md) following the [naming convention](../packages/npm_registry/_index.md#naming-convention) exist in any of the projects in the group, or in any of its subgroups.
|
||||
- `container_registry` images in the archived projects must be deleted before the transfer. For more information, see the [troubleshooting section](troubleshooting.md#missing-or-insufficient-permission-delete-button-disabled).
|
||||
- Existing packages that use a group-level endpoint (Maven, NuGet, PyPI, Composer, and Debian) need to be updated per the package's steps for setting up the group-level endpoint.
|
||||
- Existing package names need to be updated if the package uses an instance-level endpoint ([Maven](../packages/maven_repository/_index.md#naming-convention), [npm](../packages/npm_registry/_index.md#naming-convention), [Conan](../packages/conan_repository/_index.md#package-recipe-naming-convention-for-instance-remotes)) and the group was moved to another top-level group.
|
||||
- Existing package names must be updated if the package uses an instance-level endpoint ([Maven](../packages/maven_repository/_index.md#naming-convention), [npm](../packages/npm_registry/_index.md#naming-convention), [Conan 1](../packages/conan_1_repository/_index.md#package-recipe-naming-convention-for-instance-remotes)) and the group was moved to another top-level group.
|
||||
- Top-level groups that have a subscription on GitLab.com cannot be transferred. To make the transfer possible, the top-level group's subscription must be removed first. Then the top-level group can be transferred as a subgroup to another top-level group.
|
||||
|
||||
Prerequisites:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,584 @@
|
|||
---
|
||||
stage: Package
|
||||
group: Package Registry
|
||||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
|
||||
title: Conan 1 packages in the package registry
|
||||
---
|
||||
|
||||
{{< details >}}
|
||||
|
||||
- Tier: Free, Premium, Ultimate
|
||||
- Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
|
||||
- Status: Experiment
|
||||
|
||||
{{< /details >}}
|
||||
|
||||
{{< alert type="warning" >}}
|
||||
|
||||
The Conan package registry for GitLab is under development and isn't ready for production use due to
|
||||
limited functionality. This [epic](https://gitlab.com/groups/gitlab-org/-/epics/6816) details the remaining
|
||||
work and timelines to make it production ready.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
The Conan registry is not FIPS compliant and is disabled when FIPS mode is enabled.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
Publish Conan packages in your project's package registry. Then install the
|
||||
packages whenever you need to use them as a dependency.
|
||||
|
||||
To publish Conan packages to the package registry, add the package registry as a
|
||||
remote and authenticate with it.
|
||||
|
||||
Then you can run `conan` commands and publish your package to the
|
||||
package registry.
|
||||
|
||||
For documentation of the specific API endpoints that the Conan package manager client uses, see [Conan v1 API](../../../api/packages/conan_v1.md) or [Conan v2 API](../../../api/packages/conan_v2.md).
|
||||
|
||||
Learn how to [build a Conan 1 package](../workflows/build_packages.md#conan-1).
|
||||
|
||||
## Add the package registry as a Conan remote
|
||||
|
||||
To run `conan` commands, you must add the package registry as a Conan remote for
|
||||
your project or instance. Then you can publish packages to
|
||||
and install packages from the package registry.
|
||||
|
||||
### Add a remote for your project
|
||||
|
||||
Set a remote so you can work with packages in a project without
|
||||
having to specify the remote name in every command.
|
||||
|
||||
When you set a remote for a project, there are no restrictions to your package names.
|
||||
However, your commands must include the full recipe, including the user and channel,
|
||||
for example, `package_name/version@user/channel`.
|
||||
|
||||
To add the remote:
|
||||
|
||||
1. In your terminal, run this command:
|
||||
|
||||
```shell
|
||||
conan remote add gitlab https://gitlab.example.com/api/v4/projects/<project_id>/packages/conan
|
||||
```
|
||||
|
||||
1. Use the remote by adding `--remote=gitlab` to the end of your Conan command.
|
||||
|
||||
For example:
|
||||
|
||||
```shell
|
||||
conan search Hello* --remote=gitlab
|
||||
```
|
||||
|
||||
### Add a remote for your instance
|
||||
|
||||
Use a single remote to access packages across your entire GitLab instance.
|
||||
|
||||
However, when using this remote, you must follow these
|
||||
[package naming restrictions](#package-recipe-naming-convention-for-instance-remotes).
|
||||
|
||||
To add the remote:
|
||||
|
||||
1. In your terminal, run this command:
|
||||
|
||||
```shell
|
||||
conan remote add gitlab https://gitlab.example.com/api/v4/packages/conan
|
||||
```
|
||||
|
||||
1. Use the remote by adding `--remote=gitlab` to the end of your Conan command.
|
||||
|
||||
For example:
|
||||
|
||||
```shell
|
||||
conan search 'Hello*' --remote=gitlab
|
||||
```
|
||||
|
||||
#### Package recipe naming convention for instance remotes
|
||||
|
||||
The standard Conan recipe convention is `package_name/version@user/channel`, but
|
||||
if you're using an [instance remote](#add-a-remote-for-your-instance), the
|
||||
recipe `user` must be the plus sign (`+`) separated project path.
|
||||
|
||||
Example recipe names:
|
||||
|
||||
| Project | Package | Supported |
|
||||
| ---------------------- | ---------------------------------------------- | --------- |
|
||||
| `foo/bar` | `my-package/1.0.0@foo+bar/stable` | Yes |
|
||||
| `foo/bar-baz/buz` | `my-package/1.0.0@foo+bar-baz+buz/stable` | Yes |
|
||||
| `gitlab-org/gitlab-ce` | `my-package/1.0.0@gitlab-org+gitlab-ce/stable` | Yes |
|
||||
| `gitlab-org/gitlab-ce` | `my-package/1.0.0@foo/stable` | No |
|
||||
|
||||
[Project remotes](#add-a-remote-for-your-project) have a more flexible naming
|
||||
convention.
|
||||
|
||||
## Authenticate to the package registry
|
||||
|
||||
GitLab requires authentication to upload packages, and to install packages
|
||||
from private and internal projects. (You can, however, install packages
|
||||
from public projects without authentication.)
|
||||
|
||||
To authenticate to the package registry, you need one of the following:
|
||||
|
||||
- A [personal access token](../../profile/personal_access_tokens.md)
|
||||
with the scope set to `api`.
|
||||
- A [deploy token](../../project/deploy_tokens/_index.md) with the
|
||||
scope set to `read_package_registry`, `write_package_registry`, or both.
|
||||
- A [CI job token](#publish-a-conan-package-by-using-cicd).
|
||||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
Packages from private and internal projects are hidden if you are not
|
||||
authenticated. If you try to search or download a package from a private or internal
|
||||
project without authenticating, you receive the error `unable to find the package in remote`
|
||||
in the Conan client.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
### Add your credentials to the GitLab remote
|
||||
|
||||
Associate your token with the GitLab remote, so that you don't have to
|
||||
explicitly add a token to every Conan command.
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- You must have an authentication token.
|
||||
- The Conan remote [must be configured](#add-the-package-registry-as-a-conan-remote).
|
||||
|
||||
In a terminal, run this command. In this example, the remote name is `gitlab`.
|
||||
Use the name of your remote.
|
||||
|
||||
```shell
|
||||
conan user <gitlab_username or deploy_token_username> -r gitlab -p <personal_access_token or deploy_token>
|
||||
```
|
||||
|
||||
Now when you run commands with `--remote=gitlab`, your username and password are
|
||||
included in the requests.
|
||||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
Because your authentication with GitLab expires on a regular basis, you may
|
||||
occasionally need to re-enter your personal access token.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
### Set a default remote for your project (optional)
|
||||
|
||||
If you want to interact with the GitLab package registry without having to
|
||||
specify a remote, you can tell Conan to always use the package registry for your
|
||||
packages.
|
||||
|
||||
In a terminal, run this command:
|
||||
|
||||
```shell
|
||||
conan remote add_ref Hello/0.1@mycompany/beta gitlab
|
||||
```
|
||||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
The package recipe includes the version, so the default remote for
|
||||
`Hello/0.1@user/channel` doesn't work for `Hello/0.2@user/channel`.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
If you don't set a default user or remote, you can still include the user and
|
||||
remote in your commands:
|
||||
|
||||
```shell
|
||||
CONAN_LOGIN_USERNAME=<gitlab_username or deploy_token_username> CONAN_PASSWORD=<personal_access_token or deploy_token> <conan command> --remote=gitlab
|
||||
```
|
||||
|
||||
## Publish a Conan package
|
||||
|
||||
Publish a Conan package to the package registry, so that anyone who can access
|
||||
the project can use the package as a dependency.
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- The Conan remote [must be configured](#add-the-package-registry-as-a-conan-remote).
|
||||
- [Authentication](#authenticate-to-the-package-registry) with the
|
||||
package registry must be configured.
|
||||
- A local [Conan package](https://docs.conan.io/en/latest/creating_packages/getting_started.html)
|
||||
must exist.
|
||||
- For an instance remote, the package must meet the [naming convention](#package-recipe-naming-convention-for-instance-remotes).
|
||||
- You must have the project ID, which is displayed on the [project overview page](../../project/working_with_projects.md#find-the-project-id).
|
||||
|
||||
To publish the package, use the `conan upload` command:
|
||||
|
||||
```shell
|
||||
conan upload Hello/0.1@mycompany/beta --all
|
||||
```
|
||||
|
||||
## Publish a Conan package by using CI/CD
|
||||
|
||||
To work with Conan commands in [GitLab CI/CD](../../../ci/_index.md), you can
|
||||
use `CI_JOB_TOKEN` in place of the personal access token in your commands.
|
||||
|
||||
You can provide the `CONAN_LOGIN_USERNAME` and `CONAN_PASSWORD` with each Conan
|
||||
command in your `.gitlab-ci.yml` file. For example:
|
||||
|
||||
```yaml
|
||||
create_package:
|
||||
image: conanio/gcc7
|
||||
stage: deploy
|
||||
script:
|
||||
- conan remote add gitlab ${CI_API_V4_URL}/projects/$CI_PROJECT_ID/packages/conan
|
||||
- conan new <package-name>/0.1 -t
|
||||
- conan create . <group-name>+<project-name>/stable
|
||||
- CONAN_LOGIN_USERNAME=ci_user CONAN_PASSWORD=${CI_JOB_TOKEN} conan upload <package-name>/0.1@<group-name>+<project-name>/stable --all --remote=gitlab
|
||||
environment: production
|
||||
```
|
||||
|
||||
Additional Conan images to use as the basis of your CI file are available in the
|
||||
[Conan docs](https://docs.conan.io/en/latest/howtos/run_conan_in_docker.html#available-docker-images).
|
||||
|
||||
### Re-publishing a package with the same recipe
|
||||
|
||||
When you publish a package that has the same recipe (`package-name/version@user/channel`)
|
||||
as an existing package, the duplicate files are uploaded successfully and
|
||||
are accessible through the UI. However, when the package is installed,
|
||||
only the most recently-published package is returned.
|
||||
|
||||
## Install a Conan package
|
||||
|
||||
Install a Conan package from the package registry so you can use it as a
|
||||
dependency. You can install a package from the scope of your instance or your project.
|
||||
If multiple packages have the same recipe, when you install
|
||||
a package, the most recently-published package is retrieved.
|
||||
|
||||
Conan packages are often installed as dependencies by using the `conanfile.txt`
|
||||
file.
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- The Conan remote [must be configured](#add-the-package-registry-as-a-conan-remote).
|
||||
- For private and internal projects, you must configure
|
||||
[Authentication](#authenticate-to-the-package-registry)
|
||||
with the package registry.
|
||||
|
||||
1. In the project where you want to install the package as a dependency, open
|
||||
`conanfile.txt`. Or, in the root of your project, create a file called
|
||||
`conanfile.txt`.
|
||||
|
||||
1. Add the Conan recipe to the `[requires]` section of the file:
|
||||
|
||||
```plaintext
|
||||
[requires]
|
||||
Hello/0.1@mycompany/beta
|
||||
|
||||
[generators]
|
||||
cmake
|
||||
```
|
||||
|
||||
1. At the root of your project, create a `build` directory and change to that
|
||||
directory:
|
||||
|
||||
```shell
|
||||
mkdir build && cd build
|
||||
```
|
||||
|
||||
1. Install the dependencies listed in `conanfile.txt`:
|
||||
|
||||
```shell
|
||||
conan install .. <options>
|
||||
```
|
||||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
If you try installing the package you created in this tutorial, the install command
|
||||
has no effect because the package already exists.
|
||||
Delete `~/.conan/data` to clean up the packages stored in the cache.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
## Remove a Conan package
|
||||
|
||||
There are two ways to remove a Conan package from the GitLab package registry.
|
||||
|
||||
- From the command line, using the Conan client:
|
||||
|
||||
```shell
|
||||
conan remove Hello/0.2@user/channel --remote=gitlab
|
||||
```
|
||||
|
||||
You must explicitly include the remote in this command, otherwise the package
|
||||
is removed only from your local system cache.
|
||||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
This command removes all recipe and binary package files from the
|
||||
package registry.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
- From the GitLab user interface:
|
||||
|
||||
Go to your project's **Deploy > Package registry**. Remove the
|
||||
package by selecting **Remove repository** ({{< icon name="remove" >}}).
|
||||
|
||||
## Search for Conan packages in the package registry
|
||||
|
||||
To search by full or partial package name, or by exact recipe, run the
|
||||
`conan search` command.
|
||||
|
||||
- To search for all packages with a specific package name:
|
||||
|
||||
```shell
|
||||
conan search Hello --remote=gitlab
|
||||
```
|
||||
|
||||
- To search for a partial name, like all packages starting with `He`:
|
||||
|
||||
```shell
|
||||
conan search He* --remote=gitlab
|
||||
```
|
||||
|
||||
The scope of your search depends on your Conan remote configuration:
|
||||
|
||||
- If you have a remote configured for your [instance](#add-a-remote-for-your-instance), your search includes
|
||||
all projects you have permission to access. This includes your private projects
|
||||
as well as all public projects.
|
||||
|
||||
- If you have a remote configured for a [project](#add-a-remote-for-your-project), your search includes all
|
||||
packages in the target project, as long as you have permission to access it.
|
||||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
The limit of the search results is 500 packages, and the results are sorted by the most recently published packages.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
## Fetch Conan package information from the package registry
|
||||
|
||||
The `conan info` command returns information about a package:
|
||||
|
||||
```shell
|
||||
conan info Hello/0.1@mycompany/beta
|
||||
```
|
||||
|
||||
## Download a Conan package
|
||||
|
||||
{{< alert type="flag" >}}
|
||||
|
||||
Packages uploaded before [Conan info metadata extraction](#extract-conan-metadata) was enabled cannot be downloaded with the `conan download` CLI command.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
You can download a Conan package's recipe and binaries to your local cache without using settings that use the `conan download` command.
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- The Conan remote [must be configured](#add-the-package-registry-as-a-conan-remote).
|
||||
- For private and internal projects, you must configure [authentication](#authenticate-to-the-package-registry) with the package registry.
|
||||
|
||||
### Download all binary packages
|
||||
|
||||
You can download all binary packages associated with a recipe from the package registry.
|
||||
|
||||
To download all binary packages, run the following command:
|
||||
|
||||
```shell
|
||||
conan download Hello/0.1@foo+bar/stable --remote=gitlab
|
||||
```
|
||||
|
||||
### Download recipe files
|
||||
|
||||
You can download only the recipe files without any binary packages.
|
||||
|
||||
To download recipe files, run the following command:
|
||||
|
||||
```shell
|
||||
conan download Hello/0.1@foo+bar/stable --remote=gitlab --recipe
|
||||
```
|
||||
|
||||
### Download a specific binary package
|
||||
|
||||
You can download a single binary package by referencing its package reference (known as the `package_id` in Conan documentation).
|
||||
|
||||
To download a specific binary package, run the following command:
|
||||
|
||||
```shell
|
||||
conan download Hello/0.1@foo+bar/stable:<package_reference> --remote=gitlab
|
||||
```
|
||||
|
||||
## Supported CLI commands
|
||||
|
||||
The GitLab Conan repository supports the following Conan CLI commands:
|
||||
|
||||
- `conan upload`: Upload your recipe and package files to the package registry.
|
||||
- `conan install`: Install a Conan package from the package registry, which
|
||||
includes using the `conanfile.txt` file.
|
||||
- `conan download`: Download package recipes and binaries to your local cache without using settings.
|
||||
- `conan search`: Search the package registry for public packages, and private
|
||||
packages you have permission to view.
|
||||
- `conan info`: View the information on a given package from the package registry.
|
||||
- `conan remove`: Delete the package from the package registry.
|
||||
|
||||
## Extract Conan metadata
|
||||
|
||||
{{< history >}}
|
||||
|
||||
- [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/178728) in GitLab 17.10 [with a flag](../../../administration/feature_flags/_index.md) named `parse_conan_metadata_on_upload`. Disabled by default.
|
||||
- [Generally available](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/186292) in GitLab 17.11. Feature flag `parse_conan_metadata_on_upload` removed.
|
||||
|
||||
{{< /history >}}
|
||||
|
||||
When you upload a Conan package, GitLab automatically extracts metadata from the `conaninfo.txt` file. This metadata includes:
|
||||
|
||||
- Package settings (like `os`, `arch`, `compiler` and `build_type`)
|
||||
- Package options
|
||||
- Package requirements and dependencies
|
||||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
Packages uploaded before this feature was enabled (GitLab 17.10) do not have their metadata extracted. For these packages, some search and download functionalities are limited.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
## Conan revisions
|
||||
|
||||
{{< history >}}
|
||||
|
||||
- [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/519741) in GitLab 18.1 [with a flag](../../../administration/feature_flags/_index.md) named `conan_package_revisions_support`. Disabled by default.
|
||||
|
||||
{{< /history >}}
|
||||
|
||||
{{< alert type="flag" >}}
|
||||
|
||||
The availability of this feature is controlled by a feature flag. For more information, see the history.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
Conan 1 revisions are supported only when the remote is setup on a [project](#add-a-remote-for-your-project),
|
||||
not for the entire [instance](#add-a-remote-for-your-instance).
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
Conan 1 revisions provide package immutability in the package registry. When you make changes to a recipe or a package without changing its version, Conan calculates a unique identifier (revision) to track these changes.
|
||||
|
||||
### Types of revisions
|
||||
|
||||
Conan uses two types of revisions:
|
||||
|
||||
- **Recipe revisions (RREV)**: Generated when a recipe is exported. By default, Conan calculates recipe revisions using the checksum hash of the recipe manifest.
|
||||
- **Package revisions (PREV)**: Generated when a package is built. Conan calculates package revisions using the hash of the package contents.
|
||||
|
||||
### Enable revisions
|
||||
|
||||
Revisions are not enabled by default in Conan 1.x. To enable revisions, you must either:
|
||||
|
||||
- Add `revisions_enabled=1` in the `[general]` section of your `_conan.conf_` file (preferred).
|
||||
- Set the `CONAN_REVISIONS_ENABLED=1` environment variable.
|
||||
|
||||
### Reference revisions
|
||||
|
||||
You can reference packages in the following formats:
|
||||
|
||||
| Reference | Description |
|
||||
| -------------------------------------------------- | ----------------------------------------------------------------- |
|
||||
| `lib/1.0@conan/stable` | The latest RREV for `lib/1.0@conan/stable`. |
|
||||
| `lib/1.0@conan/stable#RREV` | The specific RREV for `lib/1.0@conan/stable`. |
|
||||
| `lib/1.0@conan/stable#RREV:PACKAGE_REFERENCE` | A binary package that belongs to the specific RREV. |
|
||||
| `lib/1.0@conan/stable#RREV:PACKAGE_REFERENCE#PREV` | A binary package revision PREV that belongs to the specific RREV. |
|
||||
|
||||
### Upload revisions
|
||||
|
||||
To upload all revisions and their binaries to the GitLab package registry:
|
||||
|
||||
```shell
|
||||
conan upload package_name/version@user/channel#* --all --remote=gitlab
|
||||
```
|
||||
|
||||
When you upload multiple revisions, they are uploaded from oldest to newest. The relative order is preserved in the registry.
|
||||
|
||||
### Search for revisions
|
||||
|
||||
To search for all revisions of a specific recipe in Conan v1:
|
||||
|
||||
```shell
|
||||
conan search package_name/version@user/channel --revisions --remote=gitlab
|
||||
```
|
||||
|
||||
This command displays all available revisions for the specified recipe along with their revision hashes and creation dates.
|
||||
|
||||
To get detailed information about a specific revision:
|
||||
|
||||
```shell
|
||||
conan search package_name/version@user/channel#revision_hash --remote=gitlab
|
||||
```
|
||||
|
||||
This command shows you the specific binary packages available for that revision.
|
||||
|
||||
### Delete packages with revisions
|
||||
|
||||
You can delete packages at different levels of granularity:
|
||||
|
||||
#### Delete a specific recipe revision
|
||||
|
||||
To delete a specific recipe revision and all its associated binary packages:
|
||||
|
||||
```shell
|
||||
conan remove package_name/version@user/channel#revision_hash --remote=gitlab
|
||||
```
|
||||
|
||||
#### Delete packages for a specific recipe revision
|
||||
|
||||
To delete all packages associated with a specific recipe revision:
|
||||
|
||||
```shell
|
||||
conan remove package_name/version@user/channel#revision_hash --packages --remote=gitlab
|
||||
```
|
||||
|
||||
#### Delete a specific package in a revision
|
||||
|
||||
To delete a specific package in a recipe revision, you can use either of these commands:
|
||||
|
||||
```shell
|
||||
conan remove package_name/version@user/channel#revision_hash -p package_id --remote=gitlab
|
||||
```
|
||||
|
||||
Or:
|
||||
|
||||
```shell
|
||||
conan remove package_name/version@user/channel#revision_hash:package_id --remote=gitlab
|
||||
```
|
||||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
When you delete packages with revisions, you must include the `--remote=gitlab` flag. Otherwise, the package is removed only from your local system cache.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
### Immutable revisions workflow
|
||||
|
||||
Revisions are designed to be immutable. When you modify a recipe or its source code:
|
||||
|
||||
- A new recipe revision is created when you export a recipe.
|
||||
- Any existing binaries that belong to the previous recipe revision are not included. You must build new binaries for the new recipe revision.
|
||||
- When you install a package, Conan automatically retrieves the latest revision unless you specify a revision.
|
||||
|
||||
For package binaries, you should include only one package revision per recipe revision and package reference (known as the `package_id` in Conan documentation). Multiple package revisions for the same recipe revision and package ID indicate that a package was rebuilt unnecessarily.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Make output verbose
|
||||
|
||||
For more verbose output when troubleshooting a Conan issue:
|
||||
|
||||
```shell
|
||||
export CONAN_TRACE_FILE=/tmp/conan_trace.log # Or SET in windows
|
||||
conan <command>
|
||||
```
|
||||
|
||||
You can find more logging tips in the [Conan documentation](https://docs.conan.io/en/latest/mastering/logging.html).
|
||||
|
||||
### SSL Errors
|
||||
|
||||
If you are using a self-signed certificate, there are two methods to manage SSL errors with Conan:
|
||||
|
||||
- Use the `conan remote` command to disable the SSL verification.
|
||||
- Append your server `crt` file to the `cacert.pem` file.
|
||||
|
||||
Read more about this in the [Conan Documentation](https://docs.conan.io/en/latest/howtos/use_tls_certificates.html).
|
||||
|
|
@ -0,0 +1,424 @@
|
|||
---
|
||||
stage: Package
|
||||
group: Package Registry
|
||||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
|
||||
title: Conan 2 packages in the package registry
|
||||
---
|
||||
|
||||
{{< details >}}
|
||||
|
||||
- Tier: Free, Premium, Ultimate
|
||||
- Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
|
||||
- Status: Experiment
|
||||
|
||||
{{< /details >}}
|
||||
|
||||
{{< history >}}
|
||||
|
||||
- [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/519741) in GitLab 18.1 [with a flag](../../../administration/feature_flags/_index.md) named `conan_package_revisions_support`. Disabled by default.
|
||||
|
||||
{{< /history >}}
|
||||
|
||||
{{< alert type="flag" >}}
|
||||
|
||||
The availability of this feature is controlled by a feature flag. For more information, see the history.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
{{< alert type="warning" >}}
|
||||
|
||||
The Conan 2 package registry for GitLab is under development and isn't ready for production use due to
|
||||
limited functionality. This [epic](https://gitlab.com/groups/gitlab-org/-/epics/8258) details the remaining
|
||||
work and timelines to make it production ready.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
The Conan 2 registry is not FIPS compliant and is disabled when FIPS mode is enabled.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
Publish Conan 2 packages in your project's package registry. Then install the
|
||||
packages whenever you need to use them as a dependency.
|
||||
|
||||
To publish Conan 2 packages to the package registry, add the package registry as a
|
||||
remote and authenticate with it.
|
||||
|
||||
Then you can run `conan` commands and publish your package to the
|
||||
package registry.
|
||||
|
||||
For documentation of the specific API endpoints that the Conan 2 package manager client uses, see [Conan v2 API](../../../api/packages/conan_v2.md)
|
||||
|
||||
Learn how to [build a Conan 2 package](../workflows/build_packages.md#conan-2).
|
||||
|
||||
## Add the package registry as a Conan remote
|
||||
|
||||
To run `conan` commands, you must add the package registry as a Conan remote for
|
||||
your project or instance. Then you can publish packages to
|
||||
and install packages from the package registry.
|
||||
|
||||
### Add a remote for your project
|
||||
|
||||
Set a remote so you can work with packages in a project without
|
||||
having to specify the remote name in every command.
|
||||
|
||||
When you set a remote for a project, the package names have to be lowercase.
|
||||
Also, your commands must include the full recipe, including the user and channel,
|
||||
for example, `package_name/version@user/channel`.
|
||||
|
||||
To add the remote:
|
||||
|
||||
1. In your terminal, run this command:
|
||||
|
||||
```shell
|
||||
conan remote add gitlab https://gitlab.example.com/api/v4/projects/<project_id>/packages/conan
|
||||
```
|
||||
|
||||
1. Use the remote by adding `--remote=gitlab` to the end of your Conan 2 command.
|
||||
|
||||
For example:
|
||||
|
||||
```shell
|
||||
conan search hello* --remote=gitlab
|
||||
```
|
||||
|
||||
## Authenticate to the package registry
|
||||
|
||||
GitLab requires authentication to upload packages, and to install packages
|
||||
from private and internal projects. (You can, however, install packages
|
||||
from public projects without authentication.)
|
||||
|
||||
To authenticate to the package registry, you need one of the following:
|
||||
|
||||
- A [personal access token](../../profile/personal_access_tokens.md)
|
||||
with the scope set to `api`.
|
||||
- A [deploy token](../../project/deploy_tokens/_index.md) with the
|
||||
scope set to `read_package_registry`, `write_package_registry`, or both.
|
||||
- A [CI job token](#publish-a-conan-2-package-by-using-cicd).
|
||||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
Packages from private and internal projects are hidden if you are not
|
||||
authenticated. If you try to search or download a package from a private or internal
|
||||
project without authenticating, you receive the error `unable to find the package in remote`
|
||||
in the Conan 2 client.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
### Add your credentials to the GitLab remote
|
||||
|
||||
Associate your token with the GitLab remote, so that you don't have to
|
||||
explicitly add a token to every Conan 2 command.
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- You must have an authentication token.
|
||||
- The Conan remote [must be configured](#add-the-package-registry-as-a-conan-remote).
|
||||
|
||||
In a terminal, run this command. In this example, the remote name is `gitlab`.
|
||||
Use the name of your remote.
|
||||
|
||||
```shell
|
||||
conan remote login -p <personal_access_token or deploy_token> gitlab <gitlab_username or deploy_token_username>
|
||||
```
|
||||
|
||||
Now when you run commands with `--remote=gitlab`, your username and password are
|
||||
included in the requests.
|
||||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
Because your authentication with GitLab expires on a regular basis, you may
|
||||
occasionally need to re-enter your personal access token.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
## Publish a Conan 2 package
|
||||
|
||||
Publish a Conan 2 package to the package registry, so that anyone who can access
|
||||
the project can use the package as a dependency.
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- The Conan remote [must be configured](#add-the-package-registry-as-a-conan-remote).
|
||||
- [Authentication](#authenticate-to-the-package-registry) with the
|
||||
package registry must be configured.
|
||||
- A local [Conan 2 package](../workflows/build_packages.md#conan-2)
|
||||
must exist.
|
||||
- You must have the project ID, which is displayed on the [project overview page](../../project/working_with_projects.md#find-the-project-id).
|
||||
|
||||
To publish the package, use the `conan upload` command:
|
||||
|
||||
```shell
|
||||
conan upload hello/0.1@mycompany/beta -r gitlab
|
||||
```
|
||||
|
||||
## Publish a Conan 2 package by using CI/CD
|
||||
|
||||
To work with Conan 2 commands in [GitLab CI/CD](../../../ci/_index.md), you can
|
||||
use `CI_JOB_TOKEN` in place of the personal access token in your commands.
|
||||
|
||||
You can provide the `CONAN_LOGIN_USERNAME` and `CONAN_PASSWORD` with each Conan
|
||||
command in your `.gitlab-ci.yml` file. For example:
|
||||
|
||||
```yaml
|
||||
create_package:
|
||||
image: <conan 2 image>
|
||||
stage: deploy
|
||||
script:
|
||||
- conan remote add gitlab ${CI_API_V4_URL}/projects/$CI_PROJECT_ID/packages/conan
|
||||
- conan new <package-name>/0.1
|
||||
- conan create . --channel=stable --user=mycompany
|
||||
- CONAN_LOGIN_USERNAME=ci_user CONAN_PASSWORD=${CI_JOB_TOKEN} conan upload <package-name>/0.1@mycompany/stable --remote=gitlab
|
||||
environment: production
|
||||
```
|
||||
|
||||
Follow the [official guide](https://docs.conan.io/2.17/examples/runners/docker/basic.html) to create an appropriate Conan 2 image to use as the basis of your CI file.
|
||||
|
||||
### Re-publishing a package with the same recipe
|
||||
|
||||
When you publish a package that has the same recipe (`package-name/version@user/channel`)
|
||||
as an existing package, Conan skips the upload because they are already in the server.
|
||||
|
||||
## Install a Conan 2 package
|
||||
|
||||
Install a Conan 2 package from the package registry so you can use it as a
|
||||
dependency. You can install a package from the scope of your project.
|
||||
If multiple packages have the same recipe, when you install
|
||||
a package, the most recently-published package is retrieved.
|
||||
|
||||
Conan 2 packages are often installed as dependencies by using the `conanfile.txt`
|
||||
file.
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- The Conan remote [must be configured](#add-the-package-registry-as-a-conan-remote).
|
||||
- For private and internal projects, you must configure
|
||||
[Authentication](#authenticate-to-the-package-registry)
|
||||
with the package registry.
|
||||
|
||||
1. Create another package following the [Conan 2 package](../workflows/build_packages.md#conan-2)
|
||||
guide. In the root of your project, create a file called `conanfile.txt`.
|
||||
|
||||
1. Add the Conan recipe to the `[requires]` section of the file:
|
||||
|
||||
```plaintext
|
||||
[requires]
|
||||
hello/0.1@mycompany/beta
|
||||
```
|
||||
|
||||
1. At the root of your project, create a `build` directory and change to that
|
||||
directory:
|
||||
|
||||
```shell
|
||||
mkdir build && cd build
|
||||
```
|
||||
|
||||
1. Install the dependencies listed in `conanfile.txt`:
|
||||
|
||||
```shell
|
||||
conan install ../conanfile.txt
|
||||
```
|
||||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
If you try installing the package you created in this tutorial, the install command
|
||||
has no effect because the package already exists.
|
||||
Use this command to remove an existing package locally and then try again:
|
||||
|
||||
```shell
|
||||
conan remove hello/0.1@mycompany/beta
|
||||
```
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
## Remove a Conan 2 package
|
||||
|
||||
There are two ways to remove a Conan 2 package from the GitLab package registry.
|
||||
|
||||
- From the command line, using the Conan 2 client:
|
||||
|
||||
```shell
|
||||
conan remove hello/0.1@mycompany/beta --remote=gitlab
|
||||
```
|
||||
|
||||
You must explicitly include the remote in this command, otherwise the package
|
||||
is removed only from your local system cache.
|
||||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
This command removes all recipe and binary package files from the
|
||||
package registry.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
- From the GitLab user interface:
|
||||
|
||||
Go to your project's **Deploy > Package registry**. Remove the
|
||||
package by selecting **Remove repository** ({{< icon name="remove" >}}).
|
||||
|
||||
## Search for Conan 2 packages in the package registry
|
||||
|
||||
To search by full or partial package name, or by exact recipe, run the
|
||||
`conan search` command.
|
||||
|
||||
- To search for all packages with a specific package name:
|
||||
|
||||
```shell
|
||||
conan search hello --remote=gitlab
|
||||
```
|
||||
|
||||
- To search for a partial name, like all packages starting with `he`:
|
||||
|
||||
```shell
|
||||
conan search "he*" --remote=gitlab
|
||||
```
|
||||
|
||||
The scope of your search depends on your Conan remote configuration. Your search includes all
|
||||
packages in the target project, as long as you have permission to access it.
|
||||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
The limit of the search results is 500 packages, and the results are sorted by the most recently published packages.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
## Download a Conan 2 package
|
||||
|
||||
You can download a Conan 2 package's recipe and binaries to your local cache without using settings that use the `conan download` command.
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- The Conan remote [must be configured](#add-the-package-registry-as-a-conan-remote).
|
||||
- For private and internal projects, you must configure [authentication](#authenticate-to-the-package-registry) with the package registry.
|
||||
|
||||
### Download all binary packages
|
||||
|
||||
You can download all binary packages associated with a recipe from the package registry.
|
||||
|
||||
To download all binary packages, run the following command:
|
||||
|
||||
```shell
|
||||
conan download hello/0.1@mycompany/beta --remote=gitlab
|
||||
```
|
||||
|
||||
### Download recipe files
|
||||
|
||||
You can download only the recipe files without any binary packages.
|
||||
|
||||
To download recipe files, run the following command:
|
||||
|
||||
```shell
|
||||
conan download hello/0.1@mycompany/beta --remote=gitlab --only-recipe
|
||||
```
|
||||
|
||||
### Download a specific binary package
|
||||
|
||||
You can download a single binary package by referencing its package reference (known as the `package_id` in Conan 2 documentation).
|
||||
|
||||
To download a specific binary package, run the following command:
|
||||
|
||||
```shell
|
||||
conan download Hello/0.1@foo+bar/stable:<package_reference> --remote=gitlab
|
||||
```
|
||||
|
||||
## Supported CLI commands
|
||||
|
||||
The GitLab Conan repository supports the following Conan 2 CLI commands:
|
||||
|
||||
- `conan upload`: Upload your recipe and package files to the package registry.
|
||||
- `conan install`: Install a Conan 2 package from the package registry, which
|
||||
includes using the `conanfile.txt` file.
|
||||
- `conan download`: Download package recipes and binaries to your local cache without using settings.
|
||||
- `conan search`: Search the package registry for public packages, and private
|
||||
packages you have permission to view.
|
||||
- `conan list` : List existing recipes, revisions, or packages.
|
||||
- `conan remove`: Delete the package from the package registry.
|
||||
|
||||
## Conan revisions
|
||||
|
||||
Conan revisions provide package immutability in the package registry. When you make changes to a recipe or a package without changing its version, Conan calculates a unique identifier (revision) to track these changes.
|
||||
|
||||
### Types of revisions
|
||||
|
||||
Conan uses two types of revisions:
|
||||
|
||||
- **Recipe revisions (RREV)**: Generated when a recipe is exported. By default, Conan calculates recipe revisions using the checksum hash of the recipe manifest.
|
||||
- **Package revisions (PREV)**: Generated when a package is built. Conan calculates package revisions using the hash of the package contents.
|
||||
|
||||
### Reference revisions
|
||||
|
||||
You can reference packages in the following formats:
|
||||
|
||||
| Reference | Description |
|
||||
| --- | --- |
|
||||
| `lib/1.0@conan/stable` | The latest RREV for `lib/1.0@conan/stable`. |
|
||||
| `lib/1.0@conan/stable#RREV` | The specific RREV for `lib/1.0@conan/stable`. |
|
||||
| `lib/1.0@conan/stable#RREV:PACKAGE_REFERENCE` | A binary package that belongs to the specific RREV. |
|
||||
| `lib/1.0@conan/stable#RREV:PACKAGE_REFERENCE#PREV` | A binary package revision PREV that belongs to the specific RREV. |
|
||||
|
||||
### Upload revisions
|
||||
|
||||
To upload all revisions and their binaries to the GitLab package registry:
|
||||
|
||||
```shell
|
||||
conan upload "hello/0.1@mycompany/beta#*" --remote=gitlab
|
||||
```
|
||||
|
||||
When you upload multiple revisions, they are uploaded from oldest to newest. The relative order is preserved in the registry.
|
||||
|
||||
### List revisions
|
||||
|
||||
To list all revisions of a specific recipe in Conan 2:
|
||||
|
||||
```shell
|
||||
conan list "hello/0.1@mycompany/beta#*" --remote=gitlab
|
||||
```
|
||||
|
||||
This command displays all available revisions for the specified recipe along with their revision hashes and creation dates.
|
||||
|
||||
To get detailed information about a specific revision:
|
||||
|
||||
```shell
|
||||
conan list "hello/0.1@mycompany/beta#revision_hash:*#*" --remote=gitlab
|
||||
```
|
||||
|
||||
This command shows you the specific binary packages and the package revisions available for that revision.
|
||||
|
||||
### Delete packages with revisions
|
||||
|
||||
You can delete packages at different levels of granularity:
|
||||
|
||||
#### Delete a specific recipe revision
|
||||
|
||||
To delete a specific recipe revision and all its associated binary packages:
|
||||
|
||||
```shell
|
||||
conan remove "hello/0.1@mycompany/beta#revision_hash" --remote=gitlab
|
||||
```
|
||||
|
||||
#### Delete packages for a specific recipe revision
|
||||
|
||||
To delete all packages associated with a specific recipe revision:
|
||||
|
||||
```shell
|
||||
conan remove "hello/0.1@mycompany/beta#revision_hash:*" --remote=gitlab
|
||||
```
|
||||
|
||||
#### Delete a specific package in a revision
|
||||
|
||||
To delete a specific package in a recipe revision, you can use:
|
||||
|
||||
```shell
|
||||
conan remove "package_name/version@user/channel#revision_hash:package_id" --remote=gitlab
|
||||
```
|
||||
|
||||
### Immutable revisions workflow
|
||||
|
||||
Revisions are designed to be immutable. When you modify a recipe or its source code:
|
||||
|
||||
- A new recipe revision is created when you export a recipe.
|
||||
- Any existing binaries that belong to the previous recipe revision are not included. You must build new binaries for the new recipe revision.
|
||||
- When you install a package, Conan 2 automatically retrieves the latest revision unless you specify a revision.
|
||||
|
||||
For package binaries, you should include only one package revision per recipe revision and package reference (known as the `package_id` in Conan 2 documentation). Multiple package revisions for the same recipe revision and package ID indicate that a package was rebuilt unnecessarily.
|
||||
|
|
@ -1,586 +1,13 @@
|
|||
---
|
||||
stage: Package
|
||||
group: Package Registry
|
||||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
|
||||
title: Conan packages in the package registry
|
||||
redirect_to: '../conan_1_repository/_index.md'
|
||||
remove_date: '2025-09-16'
|
||||
---
|
||||
|
||||
{{< details >}}
|
||||
<!-- markdownlint-disable -->
|
||||
|
||||
- Tier: Free, Premium, Ultimate
|
||||
- Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
|
||||
- Status: Experiment
|
||||
This document was moved to [another location](../conan_1_repository/_index.md).
|
||||
|
||||
{{< /details >}}
|
||||
|
||||
{{< alert type="warning" >}}
|
||||
|
||||
The Conan package registry for GitLab is under development and isn't ready for production use due to
|
||||
limited functionality. This [epic](https://gitlab.com/groups/gitlab-org/-/epics/6816) details the remaining
|
||||
work and timelines to make it production ready.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
The Conan registry is not FIPS compliant and is disabled when FIPS mode is enabled.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
Publish Conan packages in your project's package registry. Then install the
|
||||
packages whenever you need to use them as a dependency.
|
||||
|
||||
To publish Conan packages to the package registry, add the package registry as a
|
||||
remote and authenticate with it.
|
||||
|
||||
Then you can run `conan` commands and publish your package to the
|
||||
package registry.
|
||||
|
||||
For documentation of the specific API endpoints that the Conan package manager
|
||||
For information of the specific API endpoints used by the Conan package manager
|
||||
client, see [Conan v1 API](../../../api/packages/conan_v1.md) or [Conan v2 API](../../../api/packages/conan_v2.md).
|
||||
|
||||
Learn how to [build a Conan package](../workflows/build_packages.md#conan).
|
||||
|
||||
## Add the package registry as a Conan remote
|
||||
|
||||
To run `conan` commands, you must add the package registry as a Conan remote for
|
||||
your project or instance. Then you can publish packages to
|
||||
and install packages from the package registry.
|
||||
|
||||
### Add a remote for your project
|
||||
|
||||
Set a remote so you can work with packages in a project without
|
||||
having to specify the remote name in every command.
|
||||
|
||||
When you set a remote for a project, there are no restrictions to your package names.
|
||||
However, your commands must include the full recipe, including the user and channel,
|
||||
for example, `package_name/version@user/channel`.
|
||||
|
||||
To add the remote:
|
||||
|
||||
1. In your terminal, run this command:
|
||||
|
||||
```shell
|
||||
conan remote add gitlab https://gitlab.example.com/api/v4/projects/<project_id>/packages/conan
|
||||
```
|
||||
|
||||
1. Use the remote by adding `--remote=gitlab` to the end of your Conan command.
|
||||
|
||||
For example:
|
||||
|
||||
```shell
|
||||
conan search Hello* --remote=gitlab
|
||||
```
|
||||
|
||||
### Add a remote for your instance
|
||||
|
||||
Use a single remote to access packages across your entire GitLab instance.
|
||||
|
||||
However, when using this remote, you must follow these
|
||||
[package naming restrictions](#package-recipe-naming-convention-for-instance-remotes).
|
||||
|
||||
To add the remote:
|
||||
|
||||
1. In your terminal, run this command:
|
||||
|
||||
```shell
|
||||
conan remote add gitlab https://gitlab.example.com/api/v4/packages/conan
|
||||
```
|
||||
|
||||
1. Use the remote by adding `--remote=gitlab` to the end of your Conan command.
|
||||
|
||||
For example:
|
||||
|
||||
```shell
|
||||
conan search 'Hello*' --remote=gitlab
|
||||
```
|
||||
|
||||
#### Package recipe naming convention for instance remotes
|
||||
|
||||
The standard Conan recipe convention is `package_name/version@user/channel`, but
|
||||
if you're using an [instance remote](#add-a-remote-for-your-instance), the
|
||||
recipe `user` must be the plus sign (`+`) separated project path.
|
||||
|
||||
Example recipe names:
|
||||
|
||||
| Project | Package | Supported |
|
||||
| ---------------------- | ---------------------------------------------- | --------- |
|
||||
| `foo/bar` | `my-package/1.0.0@foo+bar/stable` | Yes |
|
||||
| `foo/bar-baz/buz` | `my-package/1.0.0@foo+bar-baz+buz/stable` | Yes |
|
||||
| `gitlab-org/gitlab-ce` | `my-package/1.0.0@gitlab-org+gitlab-ce/stable` | Yes |
|
||||
| `gitlab-org/gitlab-ce` | `my-package/1.0.0@foo/stable` | No |
|
||||
|
||||
[Project remotes](#add-a-remote-for-your-project) have a more flexible naming
|
||||
convention.
|
||||
|
||||
## Authenticate to the package registry
|
||||
|
||||
GitLab requires authentication to upload packages, and to install packages
|
||||
from private and internal projects. (You can, however, install packages
|
||||
from public projects without authentication.)
|
||||
|
||||
To authenticate to the package registry, you need one of the following:
|
||||
|
||||
- A [personal access token](../../profile/personal_access_tokens.md)
|
||||
with the scope set to `api`.
|
||||
- A [deploy token](../../project/deploy_tokens/_index.md) with the
|
||||
scope set to `read_package_registry`, `write_package_registry`, or both.
|
||||
- A [CI job token](#publish-a-conan-package-by-using-cicd).
|
||||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
Packages from private and internal projects are hidden if you are not
|
||||
authenticated. If you try to search or download a package from a private or internal
|
||||
project without authenticating, you receive the error `unable to find the package in remote`
|
||||
in the Conan client.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
### Add your credentials to the GitLab remote
|
||||
|
||||
Associate your token with the GitLab remote, so that you don't have to
|
||||
explicitly add a token to every Conan command.
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- You must have an authentication token.
|
||||
- The Conan remote [must be configured](#add-the-package-registry-as-a-conan-remote).
|
||||
|
||||
In a terminal, run this command. In this example, the remote name is `gitlab`.
|
||||
Use the name of your remote.
|
||||
|
||||
```shell
|
||||
conan user <gitlab_username or deploy_token_username> -r gitlab -p <personal_access_token or deploy_token>
|
||||
```
|
||||
|
||||
Now when you run commands with `--remote=gitlab`, your username and password are
|
||||
included in the requests.
|
||||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
Because your authentication with GitLab expires on a regular basis, you may
|
||||
occasionally need to re-enter your personal access token.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
### Set a default remote for your project (optional)
|
||||
|
||||
If you want to interact with the GitLab package registry without having to
|
||||
specify a remote, you can tell Conan to always use the package registry for your
|
||||
packages.
|
||||
|
||||
In a terminal, run this command:
|
||||
|
||||
```shell
|
||||
conan remote add_ref Hello/0.1@mycompany/beta gitlab
|
||||
```
|
||||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
The package recipe includes the version, so the default remote for
|
||||
`Hello/0.1@user/channel` doesn't work for `Hello/0.2@user/channel`.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
If you don't set a default user or remote, you can still include the user and
|
||||
remote in your commands:
|
||||
|
||||
```shell
|
||||
CONAN_LOGIN_USERNAME=<gitlab_username or deploy_token_username> CONAN_PASSWORD=<personal_access_token or deploy_token> <conan command> --remote=gitlab
|
||||
```
|
||||
|
||||
## Publish a Conan package
|
||||
|
||||
Publish a Conan package to the package registry, so that anyone who can access
|
||||
the project can use the package as a dependency.
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- The Conan remote [must be configured](#add-the-package-registry-as-a-conan-remote).
|
||||
- [Authentication](#authenticate-to-the-package-registry) with the
|
||||
package registry must be configured.
|
||||
- A local [Conan package](https://docs.conan.io/en/latest/creating_packages/getting_started.html)
|
||||
must exist.
|
||||
- For an instance remote, the package must meet the [naming convention](#package-recipe-naming-convention-for-instance-remotes).
|
||||
- You must have the project ID, which is displayed on the [project overview page](../../project/working_with_projects.md#find-the-project-id).
|
||||
|
||||
To publish the package, use the `conan upload` command:
|
||||
|
||||
```shell
|
||||
conan upload Hello/0.1@mycompany/beta --all
|
||||
```
|
||||
|
||||
## Publish a Conan package by using CI/CD
|
||||
|
||||
To work with Conan commands in [GitLab CI/CD](../../../ci/_index.md), you can
|
||||
use `CI_JOB_TOKEN` in place of the personal access token in your commands.
|
||||
|
||||
You can provide the `CONAN_LOGIN_USERNAME` and `CONAN_PASSWORD` with each Conan
|
||||
command in your `.gitlab-ci.yml` file. For example:
|
||||
|
||||
```yaml
|
||||
create_package:
|
||||
image: conanio/gcc7
|
||||
stage: deploy
|
||||
script:
|
||||
- conan remote add gitlab ${CI_API_V4_URL}/projects/$CI_PROJECT_ID/packages/conan
|
||||
- conan new <package-name>/0.1 -t
|
||||
- conan create . <group-name>+<project-name>/stable
|
||||
- CONAN_LOGIN_USERNAME=ci_user CONAN_PASSWORD=${CI_JOB_TOKEN} conan upload <package-name>/0.1@<group-name>+<project-name>/stable --all --remote=gitlab
|
||||
environment: production
|
||||
```
|
||||
|
||||
Additional Conan images to use as the basis of your CI file are available in the
|
||||
[Conan docs](https://docs.conan.io/en/latest/howtos/run_conan_in_docker.html#available-docker-images).
|
||||
|
||||
### Re-publishing a package with the same recipe
|
||||
|
||||
When you publish a package that has the same recipe (`package-name/version@user/channel`)
|
||||
as an existing package, the duplicate files are uploaded successfully and
|
||||
are accessible through the UI. However, when the package is installed,
|
||||
only the most recently-published package is returned.
|
||||
|
||||
## Install a Conan package
|
||||
|
||||
Install a Conan package from the package registry so you can use it as a
|
||||
dependency. You can install a package from the scope of your instance or your project.
|
||||
If multiple packages have the same recipe, when you install
|
||||
a package, the most recently-published package is retrieved.
|
||||
|
||||
Conan packages are often installed as dependencies by using the `conanfile.txt`
|
||||
file.
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- The Conan remote [must be configured](#add-the-package-registry-as-a-conan-remote).
|
||||
- For private and internal projects, you must configure
|
||||
[Authentication](#authenticate-to-the-package-registry)
|
||||
with the package registry.
|
||||
|
||||
1. In the project where you want to install the package as a dependency, open
|
||||
`conanfile.txt`. Or, in the root of your project, create a file called
|
||||
`conanfile.txt`.
|
||||
|
||||
1. Add the Conan recipe to the `[requires]` section of the file:
|
||||
|
||||
```plaintext
|
||||
[requires]
|
||||
Hello/0.1@mycompany/beta
|
||||
|
||||
[generators]
|
||||
cmake
|
||||
```
|
||||
|
||||
1. At the root of your project, create a `build` directory and change to that
|
||||
directory:
|
||||
|
||||
```shell
|
||||
mkdir build && cd build
|
||||
```
|
||||
|
||||
1. Install the dependencies listed in `conanfile.txt`:
|
||||
|
||||
```shell
|
||||
conan install .. <options>
|
||||
```
|
||||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
If you try installing the package you created in this tutorial, the install command
|
||||
has no effect because the package already exists.
|
||||
Delete `~/.conan/data` to clean up the packages stored in the cache.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
## Remove a Conan package
|
||||
|
||||
There are two ways to remove a Conan package from the GitLab package registry.
|
||||
|
||||
- From the command line, using the Conan client:
|
||||
|
||||
```shell
|
||||
conan remove Hello/0.2@user/channel --remote=gitlab
|
||||
```
|
||||
|
||||
You must explicitly include the remote in this command, otherwise the package
|
||||
is removed only from your local system cache.
|
||||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
This command removes all recipe and binary package files from the
|
||||
package registry.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
- From the GitLab user interface:
|
||||
|
||||
Go to your project's **Deploy > Package registry**. Remove the
|
||||
package by selecting **Remove repository** ({{< icon name="remove" >}}).
|
||||
|
||||
## Search for Conan packages in the package registry
|
||||
|
||||
To search by full or partial package name, or by exact recipe, run the
|
||||
`conan search` command.
|
||||
|
||||
- To search for all packages with a specific package name:
|
||||
|
||||
```shell
|
||||
conan search Hello --remote=gitlab
|
||||
```
|
||||
|
||||
- To search for a partial name, like all packages starting with `He`:
|
||||
|
||||
```shell
|
||||
conan search He* --remote=gitlab
|
||||
```
|
||||
|
||||
The scope of your search depends on your Conan remote configuration:
|
||||
|
||||
- If you have a remote configured for your [instance](#add-a-remote-for-your-instance), your search includes
|
||||
all projects you have permission to access. This includes your private projects
|
||||
as well as all public projects.
|
||||
|
||||
- If you have a remote configured for a [project](#add-a-remote-for-your-project), your search includes all
|
||||
packages in the target project, as long as you have permission to access it.
|
||||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
The limit of the search results is 500 packages, and the results are sorted by the most recently published packages.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
## Fetch Conan package information from the package registry
|
||||
|
||||
The `conan info` command returns information about a package:
|
||||
|
||||
```shell
|
||||
conan info Hello/0.1@mycompany/beta
|
||||
```
|
||||
|
||||
## Download a Conan package
|
||||
|
||||
{{< alert type="flag" >}}
|
||||
|
||||
Packages uploaded before [Conan info metadata extraction](#extract-conan-metadata) was enabled cannot be downloaded with the `conan download` CLI command.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
You can download a Conan package's recipe and binaries to your local cache without using settings that use the `conan download` command.
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- The Conan remote [must be configured](#add-the-package-registry-as-a-conan-remote).
|
||||
- For private and internal projects, you must configure [authentication](#authenticate-to-the-package-registry) with the package registry.
|
||||
|
||||
### Download all binary packages
|
||||
|
||||
You can download all binary packages associated with a recipe from the package registry.
|
||||
|
||||
To download all binary packages, run the following command:
|
||||
|
||||
```shell
|
||||
conan download Hello/0.1@foo+bar/stable --remote=gitlab
|
||||
```
|
||||
|
||||
### Download recipe files
|
||||
|
||||
You can download only the recipe files without any binary packages.
|
||||
|
||||
To download recipe files, run the following command:
|
||||
|
||||
```shell
|
||||
conan download Hello/0.1@foo+bar/stable --remote=gitlab --recipe
|
||||
```
|
||||
|
||||
### Download a specific binary package
|
||||
|
||||
You can download a single binary package by referencing its package reference (known as the `package_id` in Conan documentation).
|
||||
|
||||
To download a specific binary package, run the following command:
|
||||
|
||||
```shell
|
||||
conan download Hello/0.1@foo+bar/stable:<package_reference> --remote=gitlab
|
||||
```
|
||||
|
||||
## Supported CLI commands
|
||||
|
||||
The GitLab Conan repository supports the following Conan CLI commands:
|
||||
|
||||
- `conan upload`: Upload your recipe and package files to the package registry.
|
||||
- `conan install`: Install a Conan package from the package registry, which
|
||||
includes using the `conanfile.txt` file.
|
||||
- `conan download`: Download package recipes and binaries to your local cache without using settings.
|
||||
- `conan search`: Search the package registry for public packages, and private
|
||||
packages you have permission to view.
|
||||
- `conan info`: View the information on a given package from the package registry.
|
||||
- `conan remove`: Delete the package from the package registry.
|
||||
|
||||
## Extract Conan metadata
|
||||
|
||||
{{< history >}}
|
||||
|
||||
- [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/178728) in GitLab 17.10 [with a flag](../../../administration/feature_flags/_index.md) named `parse_conan_metadata_on_upload`. Disabled by default.
|
||||
- [Generally available](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/186292) in GitLab 17.11. Feature flag `parse_conan_metadata_on_upload` removed.
|
||||
|
||||
{{< /history >}}
|
||||
|
||||
When you upload a Conan package, GitLab automatically extracts metadata from the `conaninfo.txt` file. This metadata includes:
|
||||
|
||||
- Package settings (like `os`, `arch`, `compiler` and `build_type`)
|
||||
- Package options
|
||||
- Package requirements and dependencies
|
||||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
Packages uploaded before this feature was enabled (GitLab 17.10) do not have their metadata extracted. For these packages, some search and download functionalities are limited.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
## Conan revisions
|
||||
|
||||
{{< history >}}
|
||||
|
||||
- [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/519741) in GitLab 18.1 [with a flag](../../../administration/feature_flags/_index.md) named `conan_package_revisions_support`. Disabled by default.
|
||||
|
||||
{{< /history >}}
|
||||
|
||||
{{< alert type="flag" >}}
|
||||
|
||||
The availability of this feature is controlled by a feature flag. For more information, see the history.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
Conan revisions are supported only when the remote is setup on a [project](#add-a-remote-for-your-project),
|
||||
not for the entire [instance](#add-a-remote-for-your-instance).
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
Conan revisions provide package immutability in the package registry. When you make changes to a recipe or a package without changing its version, Conan calculates a unique identifier (revision) to track these changes.
|
||||
|
||||
### Types of revisions
|
||||
|
||||
Conan uses two types of revisions:
|
||||
|
||||
- **Recipe revisions (RREV)**: Generated when a recipe is exported. By default, Conan calculates recipe revisions using the checksum hash of the recipe manifest.
|
||||
- **Package revisions (PREV)**: Generated when a package is built. Conan calculates package revisions using the hash of the package contents.
|
||||
|
||||
### Enable revisions
|
||||
|
||||
Revisions are not enabled by default in Conan 1.x. To enable revisions, you must either:
|
||||
|
||||
- Add `revisions_enabled=1` in the `[general]` section of your `_conan.conf_` file (preferred).
|
||||
- Set the `CONAN_REVISIONS_ENABLED=1` environment variable.
|
||||
|
||||
### Reference revisions
|
||||
|
||||
You can reference packages in the following formats:
|
||||
|
||||
| Reference | Description |
|
||||
| --- | --- |
|
||||
| `lib/1.0@conan/stable` | The latest RREV for `lib/1.0@conan/stable`. |
|
||||
| `lib/1.0@conan/stable#RREV` | The specific RREV for `lib/1.0@conan/stable`. |
|
||||
| `lib/1.0@conan/stable#RREV:PACKAGE_REFERENCE` | A binary package that belongs to the specific RREV. |
|
||||
| `lib/1.0@conan/stable#RREV:PACKAGE_REFERENCE#PREV` | A binary package revision PREV that belongs to the specific RREV. |
|
||||
|
||||
### Upload revisions
|
||||
|
||||
To upload all revisions and their binaries to the GitLab package registry:
|
||||
|
||||
```shell
|
||||
conan upload package_name/version@user/channel#* --all --remote=gitlab
|
||||
```
|
||||
|
||||
When you upload multiple revisions, they are uploaded from oldest to newest. The relative order is preserved in the registry.
|
||||
|
||||
### Search for revisions
|
||||
|
||||
To search for all revisions of a specific recipe in Conan v1:
|
||||
|
||||
```shell
|
||||
conan search package_name/version@user/channel --revisions --remote=gitlab
|
||||
```
|
||||
|
||||
This command displays all available revisions for the specified recipe along with their revision hashes and creation dates.
|
||||
|
||||
To get detailed information about a specific revision:
|
||||
|
||||
```shell
|
||||
conan search package_name/version@user/channel#revision_hash --remote=gitlab
|
||||
```
|
||||
|
||||
This command shows you the specific binary packages available for that revision.
|
||||
|
||||
### Delete packages with revisions
|
||||
|
||||
You can delete packages at different levels of granularity:
|
||||
|
||||
#### Delete a specific recipe revision
|
||||
|
||||
To delete a specific recipe revision and all its associated binary packages:
|
||||
|
||||
```shell
|
||||
conan remove package_name/version@user/channel#revision_hash --remote=gitlab
|
||||
```
|
||||
|
||||
#### Delete packages for a specific recipe revision
|
||||
|
||||
To delete all packages associated with a specific recipe revision:
|
||||
|
||||
```shell
|
||||
conan remove package_name/version@user/channel#revision_hash --packages --remote=gitlab
|
||||
```
|
||||
|
||||
#### Delete a specific package in a revision
|
||||
|
||||
To delete a specific package in a recipe revision, you can use either of these commands:
|
||||
|
||||
```shell
|
||||
conan remove package_name/version@user/channel#revision_hash -p package_id --remote=gitlab
|
||||
```
|
||||
|
||||
Or:
|
||||
|
||||
```shell
|
||||
conan remove package_name/version@user/channel#revision_hash:package_id --remote=gitlab
|
||||
```
|
||||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
When you delete packages with revisions, you must include the `--remote=gitlab` flag. Otherwise, the package is removed only from your local system cache.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
### Immutable revisions workflow
|
||||
|
||||
Revisions are designed to be immutable. When you modify a recipe or its source code:
|
||||
|
||||
- A new recipe revision is created when you export a recipe.
|
||||
- Any existing binaries that belong to the previous recipe revision are not included. You must build new binaries for the new recipe revision.
|
||||
- When you install a package, Conan automatically retrieves the latest revision unless you specify a revision.
|
||||
|
||||
For package binaries, you should include only one package revision per recipe revision and package reference (known as the `package_id` in Conan documentation). Multiple package revisions for the same recipe revision and package ID indicate that a package was rebuilt unnecessarily.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Make output verbose
|
||||
|
||||
For more verbose output when troubleshooting a Conan issue:
|
||||
|
||||
```shell
|
||||
export CONAN_TRACE_FILE=/tmp/conan_trace.log # Or SET in windows
|
||||
conan <command>
|
||||
```
|
||||
|
||||
You can find more logging tips in the [Conan documentation](https://docs.conan.io/en/latest/mastering/logging.html).
|
||||
|
||||
### SSL Errors
|
||||
|
||||
If you are using a self-signed certificate, there are two methods to manage SSL errors with Conan:
|
||||
|
||||
- Use the `conan remote` command to disable the SSL verification.
|
||||
- Append your server `crt` file to the `cacert.pem` file.
|
||||
|
||||
Read more about this in the [Conan Documentation](https://docs.conan.io/en/latest/howtos/use_tls_certificates.html).
|
||||
<!-- This redirect file can be deleted after <2025-09-16>. -->
|
||||
<!-- Redirects that point to other docs in the same project expire in three months. -->
|
||||
<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. -->
|
||||
<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
|
||||
|
|
|
|||
|
|
@ -171,7 +171,7 @@ Several known issues exist when you allow anyone to pull from the package regist
|
|||
- Terraform module registry endpoints for namespaces are supported.
|
||||
- Other group and instance endpoints are not fully supported. Support for group endpoints is proposed in [epic 14234](https://gitlab.com/groups/gitlab-org/-/epics/14234).
|
||||
- It does not work with the [Composer](../composer_repository/_index.md#install-a-composer-package), because Composer only has a group endpoint.
|
||||
- It works with Conan, but using [`conan search`](../conan_repository/_index.md#search-for-conan-packages-in-the-package-registry) does not work.
|
||||
- It works with Conan, but using [`conan search`](../conan_1_repository/_index.md#search-for-conan-packages-in-the-package-registry) does not work.
|
||||
|
||||
## Audit events
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,8 @@ The package registry supports the following package manager types:
|
|||
| Package type | Status |
|
||||
|---------------------------------------------------|--------|
|
||||
| [Composer](../composer_repository/_index.md) | [Beta](https://gitlab.com/groups/gitlab-org/-/epics/6817) |
|
||||
| [Conan](../conan_repository/_index.md) | [Experiment](https://gitlab.com/groups/gitlab-org/-/epics/6816) |
|
||||
| [Conan 1](../conan_1_repository/_index.md) | [Experiment](https://gitlab.com/groups/gitlab-org/-/epics/6816) |
|
||||
| [Conan 2](../conan_2_repository/_index.md) | [Experiment](https://gitlab.com/groups/gitlab-org/-/epics/8258) |
|
||||
| [Debian](../debian_repository/_index.md) | [Experiment](https://gitlab.com/groups/gitlab-org/-/epics/6057) |
|
||||
| [Generic packages](../generic_packages/_index.md) | Generally available |
|
||||
| [Go](../go_proxy/_index.md) | [Experiment](https://gitlab.com/groups/gitlab-org/-/epics/3043) |
|
||||
|
|
@ -65,7 +66,8 @@ Packages can be published to your project, group, or instance.
|
|||
| [Generic packages](../generic_packages/_index.md) | Y | N | N |
|
||||
| [Terraform](../terraform_module_registry/_index.md) | Y | N | N |
|
||||
| [Composer](../composer_repository/_index.md) | N | Y | N |
|
||||
| [Conan](../conan_repository/_index.md) | Y | N | Y |
|
||||
| [Conan 1](../conan_1_repository/_index.md) | Y | N | Y |
|
||||
| [Conan 2](../conan_2_repository/_index.md) | Y | N | N |
|
||||
| [Helm](../helm_repository/_index.md) | Y | N | N |
|
||||
| [Debian](../debian_repository/_index.md) | Y | N | N |
|
||||
| [Go](../go_proxy/_index.md) | Y | N | N |
|
||||
|
|
@ -93,7 +95,8 @@ Packages can be pulled from your project, group, or instance.
|
|||
| [Generic packages](../generic_packages/_index.md) | Y | N | N |
|
||||
| [Terraform](../terraform_module_registry/_index.md) | N | Y | N |
|
||||
| [Composer](../composer_repository/_index.md) | Y | Y | N |
|
||||
| [Conan](../conan_repository/_index.md) | Y | N | Y |
|
||||
| [Conan 1](../conan_1_repository/_index.md) | Y | N | Y |
|
||||
| [Conan 2](../conan_2_repository/_index.md) | Y | N | N |
|
||||
| [Helm](../helm_repository/_index.md) | Y | N | N |
|
||||
| [Debian](../debian_repository/_index.md) | Y | N | N |
|
||||
| [Go](../go_proxy/_index.md) | Y | N | Y |
|
||||
|
|
@ -131,7 +134,8 @@ To reduce the associated security risks:
|
|||
| [Generic packages](../generic_packages/_index.md) | N | N |
|
||||
| [Terraform](../terraform_module_registry/_index.md) | N | N |
|
||||
| [Composer](../composer_repository/_index.md) | N | N |
|
||||
| [Conan](../conan_repository/_index.md) | N | N |
|
||||
| [Conan 1](../conan_1_repository/_index.md) | N | N |
|
||||
| [Conan 2](../conan_2_repository/_index.md) | N | N |
|
||||
| [Helm](../helm_repository/_index.md) | N | N |
|
||||
| [Debian](../debian_repository/_index.md) | N | N |
|
||||
| [Go](../go_proxy/_index.md) | N | N |
|
||||
|
|
@ -169,7 +173,8 @@ You can use GitLab pipelines to import packages from other repositories, such as
|
|||
| [Generic packages](../generic_packages/_index.md) | N |
|
||||
| [Terraform](../terraform_module_registry/_index.md) | N |
|
||||
| [Composer](../composer_repository/_index.md) | N |
|
||||
| [Conan](../conan_repository/_index.md) | N |
|
||||
| [Conan 1](../conan_1_repository/_index.md) | N |
|
||||
| [Conan 2](../conan_2_repository/_index.md) | N |
|
||||
| [Helm](../helm_repository/_index.md) | N |
|
||||
| [Debian](../debian_repository/_index.md) | N |
|
||||
| [Go](../go_proxy/_index.md) | N |
|
||||
|
|
@ -197,7 +202,8 @@ By default, the GitLab package registry either allows or prevents duplicates bas
|
|||
| [Generic packages](../generic_packages/_index.md) | Y (configurable) |
|
||||
| [Terraform](../terraform_module_registry/_index.md) | N |
|
||||
| [Composer](../composer_repository/_index.md) | N |
|
||||
| [Conan](../conan_repository/_index.md) | N |
|
||||
| [Conan 1](../conan_1_repository/_index.md) | N |
|
||||
| [Conan 2](../conan_2_repository/_index.md) | N |
|
||||
| [Helm](../helm_repository/_index.md) | Y |
|
||||
| [Debian](../debian_repository/_index.md) | Y |
|
||||
| [Go](../go_proxy/_index.md) | N |
|
||||
|
|
@ -235,7 +241,8 @@ for a given package manager:
|
|||
| [Generic packages](../generic_packages/_index.md) | Personal access, job tokens, deploy (project or group), project access |
|
||||
| [Terraform](../terraform_module_registry/_index.md) | Personal access, job tokens, deploy (project or group), project access |
|
||||
| [Composer](../composer_repository/_index.md) | Personal access, job tokens, deploy (project or group), project access |
|
||||
| [Conan](../conan_repository/_index.md) | Personal access, job tokens, project access |
|
||||
| [Conan 1](../conan_1_repository/_index.md) | Personal access, job tokens, project access |
|
||||
| [Conan 2](../conan_2_repository/_index.md) | Personal access, job tokens, project access |
|
||||
| [Helm](../helm_repository/_index.md) | Personal access, job tokens, deploy (project or group) |
|
||||
| [Debian](../debian_repository/_index.md) | Personal access, job tokens, deploy (project or group) |
|
||||
| [Go](../go_proxy/_index.md) | Personal access, job tokens, project access |
|
||||
|
|
@ -280,7 +287,8 @@ The following authentication protocols are supported:
|
|||
| [Generic packages](../generic_packages/_index.md) | Basic auth |
|
||||
| [Terraform](../terraform_module_registry/_index.md) | Token |
|
||||
| [Composer](../composer_repository/_index.md) | OAuth |
|
||||
| [Conan](../conan_repository/_index.md) | OAuth, Basic auth |
|
||||
| [Conan 1](../conan_1_repository/_index.md) | OAuth, Basic auth |
|
||||
| [Conan 2](../conan_2_repository/_index.md) | OAuth, Basic auth |
|
||||
| [Helm](../helm_repository/_index.md) | Basic auth |
|
||||
| [Debian](../debian_repository/_index.md) | Basic auth |
|
||||
| [Go](../go_proxy/_index.md) | Basic auth |
|
||||
|
|
@ -309,7 +317,8 @@ The package registry supports the following hash types:
|
|||
| [PyPI](../pypi_repository/_index.md) | MD5, SHA256 |
|
||||
| [Generic packages](../generic_packages/_index.md) | SHA256 |
|
||||
| [Composer](../composer_repository/_index.md) | not applicable |
|
||||
| [Conan](../conan_repository/_index.md) | MD5, SHA1 |
|
||||
| [Conan 1](../conan_1_repository/_index.md) | MD5, SHA1 |
|
||||
| [Conan 2](../conan_2_repository/_index.md) | MD5, SHA1 |
|
||||
| [Helm](../helm_repository/_index.md) | not applicable |
|
||||
| [Debian](../debian_repository/_index.md) | MD5, SHA1, SHA256 |
|
||||
| [Go](../go_proxy/_index.md) | MD5, SHA1, SHA256 |
|
||||
|
|
|
|||
|
|
@ -10,9 +10,11 @@ Use the GitLab package registry to install and build packages for different pack
|
|||
The following package managers are supported:
|
||||
|
||||
- [Composer](#composer)
|
||||
- [Conan](#conan)
|
||||
- [Conan 1](#conan-1)
|
||||
- [Conan 2](#conan-2)
|
||||
- [Maven](#maven)
|
||||
- [Gradle](#gradle)
|
||||
- [sbt](#sbt)
|
||||
- [npm](#npm)
|
||||
- [Yarn](#yarn)
|
||||
- [NuGet](#nuget)
|
||||
|
|
@ -48,13 +50,13 @@ The following package managers are supported:
|
|||
}
|
||||
```
|
||||
|
||||
## Conan
|
||||
## Conan 1
|
||||
|
||||
### Install Conan
|
||||
### Install Conan 1
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- You must install Conan version 1.x. Support for Conan version 2 is proposed in [epic 8258](https://gitlab.com/groups/gitlab-org/-/epics/8258).
|
||||
- You must install Conan version 1.x.
|
||||
|
||||
Download the Conan package manager to your local development environment by
|
||||
following the instructions at [conan.io](https://conan.io/downloads).
|
||||
|
|
@ -96,7 +98,7 @@ The CMake version is printed in the output.
|
|||
To test the package registry, you need a C++ project. If you don't already have
|
||||
one, you can clone the Conan [hello world starter project](https://github.com/conan-io/hello).
|
||||
|
||||
### Build a Conan package
|
||||
### Build a Conan 1 package
|
||||
|
||||
To build a package:
|
||||
|
||||
|
|
@ -116,8 +118,8 @@ To build a package:
|
|||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
If you use an [instance remote](../conan_repository/_index.md#add-a-remote-for-your-instance), you must
|
||||
follow a specific [naming convention](../conan_repository/_index.md#package-recipe-naming-convention-for-instance-remotes).
|
||||
If you use an [instance remote](../conan_1_repository/_index.md#add-a-remote-for-your-instance), you must
|
||||
follow a specific [naming convention](../conan_1_repository/_index.md#package-recipe-naming-convention-for-instance-remotes).
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
|
|
@ -126,6 +128,111 @@ A package with the recipe `Hello/0.1@mycompany/beta` is created.
|
|||
For more details about creating and managing Conan packages, see the
|
||||
[Conan documentation](https://docs.conan.io/en/latest/creating_packages.html).
|
||||
|
||||
## Conan 2
|
||||
|
||||
### Install Conan 2
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- You must install Conan version 2.x. Base Conan version 2 is available and future improvements can be tracked in [epic 8258](https://gitlab.com/groups/gitlab-org/-/epics/8258).
|
||||
|
||||
Install the Conan package manager to your local development environment by
|
||||
following the instructions at [conan.io](https://docs.conan.io/2/installation.html).
|
||||
|
||||
When you complete the installation, run the following command to verify you can use Conan in your terminal:
|
||||
|
||||
```shell
|
||||
conan --version
|
||||
```
|
||||
|
||||
The Conan version is printed in the output:
|
||||
|
||||
```plaintext
|
||||
Conan version 2.17.0
|
||||
```
|
||||
|
||||
### Create Conan 2 profile
|
||||
|
||||
You must define a profile for Conan 2. If you already defined a profile, skip this step.
|
||||
|
||||
To create a profile, run the following command:
|
||||
|
||||
```shell
|
||||
conan profile detect
|
||||
```
|
||||
|
||||
Check the profile:
|
||||
|
||||
```shell
|
||||
conan profile list
|
||||
```
|
||||
|
||||
The command lists the profile in the output:
|
||||
|
||||
```plaintext
|
||||
Profiles found in the cache:
|
||||
default
|
||||
```
|
||||
|
||||
The generated profile is usually enough to get started. For more information on Conan profiles, see [Conan 2 profiles](https://docs.conan.io/2/reference/config_files/profiles.html#profiles).
|
||||
|
||||
### Install CMake
|
||||
|
||||
When you develop with C++ and Conan, you can select from many available
|
||||
compilers. The following example uses the CMake build system generator.
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- Install CMake.
|
||||
- For macOS, install [Homebrew](https://brew.sh/) and run `brew install cmake`.
|
||||
- For other operating systems, follow the instructions at [cmake.org](https://cmake.org/resources/).
|
||||
|
||||
When installation is complete, verify you can use CMake in your terminal with
|
||||
the following command:
|
||||
|
||||
```shell
|
||||
cmake --version
|
||||
```
|
||||
|
||||
The CMake version is printed in the output.
|
||||
|
||||
### Create a project
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- To test the package registry, you must have a C++ project.
|
||||
|
||||
Go to your local project folder and use the `conan new` command to create a `“Hello World”` C++ library example project with the `cmake_lib` template:
|
||||
|
||||
```shell
|
||||
mkdir hello && cd hello
|
||||
conan new cmake_lib -d name=hello -d version=0.1
|
||||
```
|
||||
|
||||
For more advanced examples, see the Conan 2 [examples project](https://github.com/conan-io/examples2).
|
||||
|
||||
### Build a Conan 2 package
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- [Create a C++ project](#create-a-project).
|
||||
|
||||
To build a package:
|
||||
|
||||
1. Make sure you are in the `hello` folder created in the previous section.
|
||||
|
||||
1. Create a package for the recipe by running `conan create` with the Conan user
|
||||
and channel:
|
||||
|
||||
```shell
|
||||
conan create . --channel=beta --user=mycompany
|
||||
```
|
||||
|
||||
A package with the recipe `hello/0.1@mycompany/beta` is created.
|
||||
|
||||
For more details about creating and managing Conan packages, see
|
||||
[Creating packages](https://docs.conan.io/2/tutorial/creating_packages).
|
||||
|
||||
## Maven
|
||||
|
||||
### Install Maven
|
||||
|
|
|
|||
|
|
@ -70,22 +70,31 @@ appropriate URL for your project, as described in the [GitLab Maven Repository d
|
|||
Then, you need to add a `settings.xml` file and [include your access token](../maven_repository/_index.md#authenticate-to-the-package-registry).
|
||||
Now you can [publish Maven packages](../maven_repository/_index.md#publish-a-package) to your project.
|
||||
|
||||
### Conan
|
||||
### Conan 1
|
||||
|
||||
For Conan, you need to add GitLab as a Conan registry remote. Follow the instructions in the
|
||||
[GitLab Conan Repository docs](../conan_repository/_index.md#add-the-package-registry-as-a-conan-remote).
|
||||
For Conan 1, you must add GitLab as a Conan registry remote. For instructions, see
|
||||
[Add the package registry as a Conan remote](../conan_1_repository/_index.md#add-the-package-registry-as-a-conan-remote).
|
||||
Then, create your package using the plus-separated (`+`) project path as your Conan user. For example,
|
||||
if your project is located at `https://gitlab.com/foo/bar/my-proj`,
|
||||
[create your Conan package](../conan_repository/_index.md) using `conan create . foo+bar+my-proj/channel`.
|
||||
[create your Conan package](build_packages.md#conan-1) using `conan create . foo+bar+my-proj/channel`.
|
||||
`channel` is your package channel (such as `stable` or `beta`).
|
||||
|
||||
After you create your package, you're ready to [publish your package](../conan_repository/_index.md#publish-a-conan-package),
|
||||
After you create your package, you're ready to [publish your package](../conan_1_repository/_index.md#publish-a-conan-package),
|
||||
depending on your final package recipe. For example:
|
||||
|
||||
```shell
|
||||
CONAN_LOGIN_USERNAME=<gitlab-username> CONAN_PASSWORD=<personal_access_token> conan upload MyPackage/1.0.0@foo+bar+my-proj/channel --all --remote=gitlab
|
||||
```
|
||||
|
||||
### Conan 2
|
||||
|
||||
For Conan 2, you must add GitLab as a Conan registry remote. For instructions, see
|
||||
[Add the package registry as a Conan remote](../conan_2_repository/_index.md#add-the-package-registry-as-a-conan-remote).
|
||||
Then, [create your Conan 2 package](build_packages.md#conan-2).
|
||||
|
||||
After you create your package, you're ready to [publish your package](../conan_2_repository/_index.md#publish-a-conan-2-package),
|
||||
depending on your final package recipe.
|
||||
|
||||
### Composer
|
||||
|
||||
You can't publish a Composer package outside of its project. An [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/250633)
|
||||
|
|
|
|||
|
|
@ -1,125 +1,13 @@
|
|||
---
|
||||
stage: Tenant Scale
|
||||
group: Organizations
|
||||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
|
||||
title: Transfer projects
|
||||
redirect_to: '../working_with_projects.md'
|
||||
remove_date: '2025-10-01'
|
||||
---
|
||||
|
||||
{{< details >}}
|
||||
<!-- markdownlint-disable -->
|
||||
|
||||
- Tier: Free, Premium, Ultimate
|
||||
- Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
|
||||
This document was moved to [another location](../working_with_projects.md).
|
||||
|
||||
{{< /details >}}
|
||||
|
||||
## Transfer a project to another namespace
|
||||
|
||||
{{< history >}}
|
||||
|
||||
- Support for transferring projects with container images within the same top-level namespace [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/499163) on GitLab.com in GitLab 17.7 [with a flag](../../../administration/feature_flags/_index.md) named `transfer_project_with_tags`. Disabled by default.
|
||||
- Support for transferring projects with container images within the same top-level namespace [enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/499163) in GitLab 17.7. Feature flag removed.
|
||||
|
||||
{{< /history >}}
|
||||
|
||||
Transfer a project to move it to a different group.
|
||||
A project transfer includes:
|
||||
|
||||
- Project components:
|
||||
- Issues
|
||||
- Merge requests
|
||||
- Pipelines
|
||||
- Dashboards
|
||||
- Project members:
|
||||
- Direct members
|
||||
- Membership invitations
|
||||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
Members with [inherited membership](../members/_index.md#membership-types)
|
||||
in the project lose access unless they are also members of the target group.
|
||||
The project inherits new member permissions from the group you transfer it to.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
The project's [path also changes](../repository/_index.md#repository-path-changes), so make sure to update the URLs to the project components where necessary.
|
||||
|
||||
New project-level labels are created for issues and merge requests if matching group labels don't already exist in the target namespace.
|
||||
|
||||
If a project contains issues assigned to an epic, and that epic is not available in the target
|
||||
group, GitLab creates a copy of the epic in the target group. When you transfer multiple projects
|
||||
with issues assigned to the same epic, GitLab creates a separate copy of that epic in the target
|
||||
group for each project.
|
||||
|
||||
{{< alert type="warning" >}}
|
||||
|
||||
Errors during the transfer process may lead to data loss of the project's components or dependencies of end users.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- You must have at least the Maintainer role for the [group](../../group/_index.md#create-a-group) you are transferring to.
|
||||
- You must be the Owner of the project you transfer.
|
||||
- The group must allow creation of new projects.
|
||||
- For projects where the container registry is enabled:
|
||||
- On GitLab.com: You can only transfer projects within the same top-level namespace.
|
||||
- On GitLab Self-Managed: The project must not contain [container images](../../packages/container_registry/_index.md#move-or-rename-container-registry-repositories).
|
||||
- The project must not have a security policy.
|
||||
If a security policy is assigned to the project, it is automatically unassigned during the transfer.
|
||||
- If the root namespace changes, you must remove npm packages that follow the [naming convention](../../packages/npm_registry/_index.md#naming-convention) from the project.
|
||||
After you transfer the project you can either:
|
||||
|
||||
- Update the package scope with the new root namespace path, and publish it again to the project.
|
||||
- Republish the package to the project without updating the root namespace path, which causes the package to no longer follow the naming convention.
|
||||
If you republish the package without updating the root namespace path, it will not be available for the [instance endpoint](../../packages/npm_registry/_index.md#install-from-an-instance).
|
||||
|
||||
To transfer a project:
|
||||
|
||||
1. On the left sidebar, select **Search or go to** and find your project.
|
||||
1. Select **Settings > General**.
|
||||
1. Expand **Advanced**.
|
||||
1. Under **Transfer project**, choose the namespace to transfer the project to.
|
||||
1. Select **Transfer project**.
|
||||
1. Enter the project's name and select **Confirm**.
|
||||
|
||||
You are redirected to the project's new page and GitLab applies a redirect. For more information about repository redirects, see [What happens when a repository path changes](../repository/_index.md#repository-path-changes).
|
||||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
If you are an administrator, you can also use the [administration interface](../../../administration/admin_area.md#administering-projects)
|
||||
to move any project to any namespace.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
## Transferring a GitLab.com project to a different subscription tier
|
||||
|
||||
When you transfer a project from a namespace licensed for GitLab.com Premium or Ultimate to GitLab Free:
|
||||
|
||||
- [Project access tokens](project_access_tokens.md) are revoked.
|
||||
- [Pipeline subscriptions](../../../ci/pipelines/_index.md#trigger-a-pipeline-when-an-upstream-project-is-rebuilt-deprecated)
|
||||
and [test cases](../../../ci/test_cases/_index.md) are deleted.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
When working with project settings, you might encounter the following issues, or require alternate methods to complete specific tasks.
|
||||
|
||||
### Transfer a project through console
|
||||
|
||||
If transferring a project through the UI or API is not working, you can attempt the transfer in a [Rails console session](../../../administration/operations/rails_console.md#starting-a-rails-console-session).
|
||||
|
||||
```ruby
|
||||
p = Project.find_by_full_path('<project_path>')
|
||||
|
||||
# To set the owner of the project
|
||||
current_user = p.creator
|
||||
|
||||
# Namespace where you want this to be moved
|
||||
namespace = Namespace.find_by_full_path("<new_namespace>")
|
||||
|
||||
Projects::TransferService.new(p, current_user).execute(namespace)
|
||||
```
|
||||
|
||||
## Related topics
|
||||
|
||||
- [Migrating projects using file exports](import_export.md)
|
||||
- [Troubleshooting file export project migrations](import_export_troubleshooting.md)
|
||||
<!-- This redirect file can be deleted after <2025-10-01>. -->
|
||||
<!-- Redirects that point to other docs in the same project expire in three months. -->
|
||||
<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
|
||||
<!-- Before deletion, see: https://docs.gitlab.com/development/documentation/redirects -->
|
||||
|
|
@ -57,6 +57,22 @@ projects.each do |p|
|
|||
end
|
||||
```
|
||||
|
||||
### Transfer a project using console
|
||||
|
||||
If transferring a project through the UI or API is not working, you can attempt the transfer in a [Rails console session](../../administration/operations/rails_console.md#starting-a-rails-console-session).
|
||||
|
||||
```ruby
|
||||
p = Project.find_by_full_path('<project_path>')
|
||||
|
||||
# To set the owner of the project
|
||||
current_user = p.creator
|
||||
|
||||
# Namespace where you want this to be moved
|
||||
namespace = Namespace.find_by_full_path("<new_namespace>")
|
||||
|
||||
Projects::TransferService.new(p, current_user).execute(namespace)
|
||||
```
|
||||
|
||||
## Delete a project using console
|
||||
|
||||
If a project cannot be deleted, you can attempt to delete it through [Rails console](../../administration/operations/rails_console.md#starting-a-rails-console-session).
|
||||
|
|
|
|||
|
|
@ -240,6 +240,91 @@ To star a project:
|
|||
1. On the left sidebar, select **Search or go to** and find your project.
|
||||
1. In the upper-right corner of the page, select **Star**.
|
||||
|
||||
## Transfer a project
|
||||
|
||||
{{< history >}}
|
||||
|
||||
- Support for transferring projects with container images within the same top-level namespace [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/499163) on GitLab.com in GitLab 17.7 [with a flag](../../administration/feature_flags/_index.md) named `transfer_project_with_tags`. Disabled by default.
|
||||
- Support for transferring projects with container images within the same top-level namespace [enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/499163) in GitLab 17.7. Feature flag removed.
|
||||
|
||||
{{< /history >}}
|
||||
|
||||
Transfer a project to move it to a different group.
|
||||
A project transfer includes:
|
||||
|
||||
- Project components:
|
||||
- Issues
|
||||
- Merge requests
|
||||
- Pipelines
|
||||
- Dashboards
|
||||
- Project members:
|
||||
- Direct members
|
||||
- Membership invitations
|
||||
|
||||
{{< alert type="note" >}}
|
||||
|
||||
Members with [inherited membership](members/_index.md#membership-types)
|
||||
in the project lose access unless they are also members of the target group.
|
||||
The project inherits new member permissions from the group you transfer it to.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
The project's [path also changes](repository/_index.md#repository-path-changes), so make sure to update the URLs to the project components where necessary.
|
||||
|
||||
New project-level labels are created for issues and merge requests if matching group labels don't already exist in the target namespace.
|
||||
|
||||
If a project contains issues assigned to an epic, and that epic is not available in the target
|
||||
group, GitLab creates a copy of the epic in the target group. When you transfer multiple projects
|
||||
with issues assigned to the same epic, GitLab creates a separate copy of that epic in the target
|
||||
group for each project.
|
||||
|
||||
{{< alert type="warning" >}}
|
||||
|
||||
Errors during the transfer process may lead to data loss of the project's components or dependencies of end users.
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- You must have at least the Maintainer role for the [group](../group/_index.md#create-a-group) you are transferring to.
|
||||
- You must be the Owner of the project you transfer.
|
||||
- The group must allow creation of new projects.
|
||||
- For projects where the container registry is enabled:
|
||||
- On GitLab.com: You can only transfer projects within the same top-level namespace.
|
||||
- On GitLab Self-Managed: The project must not contain [container images](../packages/container_registry/_index.md#move-or-rename-container-registry-repositories).
|
||||
- The project must not have a security policy.
|
||||
If a security policy is assigned to the project, it is automatically unassigned during the transfer.
|
||||
- If the root namespace changes, you must remove npm packages that follow the [naming convention](../packages/npm_registry/_index.md#naming-convention) from the project.
|
||||
After you transfer the project you can either:
|
||||
|
||||
- Update the package scope with the new root namespace path, and publish it again to the project.
|
||||
- Republish the package to the project without updating the root namespace path, which causes the package to no longer follow the naming convention.
|
||||
If you republish the package without updating the root namespace path, it will not be available for the [instance endpoint](../packages/npm_registry/_index.md#install-from-an-instance).
|
||||
|
||||
To transfer a project:
|
||||
|
||||
1. On the left sidebar, select **Search or go to** and find your project.
|
||||
1. Select **Settings > General**.
|
||||
1. Expand **Advanced**.
|
||||
1. Under **Transfer project**, choose the namespace to transfer the project to.
|
||||
1. Select **Transfer project**.
|
||||
1. Enter the project's name and select **Confirm**.
|
||||
|
||||
You are redirected to the project's new page and GitLab applies a redirect. For more information about repository redirects, see [repository path changes](repository/_index.md#repository-path-changes).
|
||||
|
||||
{{< alert type="note" >}}
|
||||
Administrators can also transfer projects from the [Admin area](../../administration/admin_area.md#administering-projects).
|
||||
|
||||
{{< /alert >}}
|
||||
|
||||
### Transfer a GitLab.com project to a different subscription tier
|
||||
|
||||
When you transfer a project from a namespace licensed for GitLab.com Premium or Ultimate to GitLab Free:
|
||||
|
||||
- [Project access tokens](settings/project_access_tokens.md) are revoked.
|
||||
- [Pipeline subscriptions](../../ci/pipelines/_index.md#trigger-a-pipeline-when-an-upstream-project-is-rebuilt-deprecated)
|
||||
and [test cases](../../ci/test_cases/_index.md) are deleted.
|
||||
|
||||
## Delete a project
|
||||
|
||||
{{< history >}}
|
||||
|
|
|
|||
|
|
@ -35,6 +35,7 @@ module API
|
|||
optional :search, type: String, desc: 'Returns a list of namespaces the user is authorized to view based on the search criteria'
|
||||
optional :owned_only, type: Boolean, desc: 'In GitLab 14.2 and later, returns a list of owned namespaces only'
|
||||
optional :top_level_only, type: Boolean, default: false, desc: 'Only include top level namespaces'
|
||||
optional :full_path_search, type: Boolean, default: false, desc: 'If `true`, the `search` parameter is matched against the full path of the namespaces'
|
||||
|
||||
use :pagination
|
||||
use :optional_list_params_ee
|
||||
|
|
@ -50,7 +51,9 @@ module API
|
|||
|
||||
namespaces = namespaces.include_gitlab_subscription_with_hosted_plan if Gitlab.ee?
|
||||
|
||||
namespaces = namespaces.search(params[:search]) if params[:search].present?
|
||||
if params[:search].present?
|
||||
namespaces = namespaces.search(params[:search], include_parents: params[:full_path_search])
|
||||
end
|
||||
|
||||
options = { with: Entities::Namespace, current_user: current_user }
|
||||
|
||||
|
|
|
|||
|
|
@ -57019,12 +57019,18 @@ msgstr ""
|
|||
msgid "SecurityOrchestration|all namespaces"
|
||||
msgstr ""
|
||||
|
||||
msgid "SecurityOrchestration|all projects in the groups"
|
||||
msgstr ""
|
||||
|
||||
msgid "SecurityOrchestration|all projects in the linked groups"
|
||||
msgstr ""
|
||||
|
||||
msgid "SecurityOrchestration|all projects in this group"
|
||||
msgstr ""
|
||||
|
||||
msgid "SecurityOrchestration|all projects in this instance"
|
||||
msgstr ""
|
||||
|
||||
msgid "SecurityOrchestration|allowlist"
|
||||
msgstr ""
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,63 @@
|
|||
diff --git a/node_modules/highlight.js/es/languages/ruby.js b/node_modules/highlight.js/es/languages/ruby.js
|
||||
index 2b1d275..afbd10e 100644
|
||||
--- a/node_modules/highlight.js/es/languages/ruby.js
|
||||
+++ b/node_modules/highlight.js/es/languages/ruby.js
|
||||
@@ -227,6 +227,27 @@ function ruby(hljs) {
|
||||
]
|
||||
};
|
||||
|
||||
+ const REGEXP = {
|
||||
+ className: 'regexp',
|
||||
+ contains: [
|
||||
+ hljs.BACKSLASH_ESCAPE,
|
||||
+ SUBST,
|
||||
+ {
|
||||
+ begin: /\{/, end: /\}/,
|
||||
+ contains: ['self', hljs.BACKSLASH_ESCAPE, SUBST],
|
||||
+ relevance: 0
|
||||
+ }
|
||||
+ ],
|
||||
+ illegal: /\n/,
|
||||
+ variants: [
|
||||
+ { begin: /%r\{/, end: /\}[a-z]*/ },
|
||||
+ { begin: '%r\\(', end: '\\)[a-z]*' },
|
||||
+ { begin: '%r!', end: '![a-z]*' },
|
||||
+ { begin: '%r\\[', end: '\\][a-z]*' },
|
||||
+ { begin: '/', end: '/[a-z]*' }
|
||||
+ ]
|
||||
+ };
|
||||
+
|
||||
const PARAMS = {
|
||||
variants: [
|
||||
{
|
||||
@@ -324,6 +345,7 @@ function ruby(hljs) {
|
||||
UPPER_CASE_CONSTANT,
|
||||
CLASS_REFERENCE,
|
||||
METHOD_DEFINITION,
|
||||
+ REGEXP,
|
||||
{
|
||||
// swallow namespace qualifiers before symbols
|
||||
begin: hljs.IDENT_RE + '::' },
|
||||
@@ -373,22 +395,6 @@ function ruby(hljs) {
|
||||
begin: '/',
|
||||
end: '/[a-z]*'
|
||||
},
|
||||
- {
|
||||
- begin: /%r\{/,
|
||||
- end: /\}[a-z]*/
|
||||
- },
|
||||
- {
|
||||
- begin: '%r\\(',
|
||||
- end: '\\)[a-z]*'
|
||||
- },
|
||||
- {
|
||||
- begin: '%r!',
|
||||
- end: '![a-z]*'
|
||||
- },
|
||||
- {
|
||||
- begin: '%r\\[',
|
||||
- end: '\\][a-z]*'
|
||||
- }
|
||||
]
|
||||
}
|
||||
].concat(IRB_OBJECT, COMMENT_MODES),
|
||||
|
|
@ -104,17 +104,14 @@ spec/frontend/projects/settings/components/branch_rule_modal_spec.js
|
|||
spec/frontend/projects/settings_service_desk/components/service_desk_root_spec.js
|
||||
spec/frontend/ref/init_ambiguous_ref_modal_spec.js
|
||||
spec/frontend/releases/components/asset_links_form_spec.js
|
||||
spec/frontend/set_status_modal/user_profile_set_status_wrapper_spec.js
|
||||
spec/frontend/sidebar/components/confidential/confidentiality_dropdown_spec.js
|
||||
spec/frontend/sidebar/components/confidential/sidebar_confidentiality_widget_spec.js
|
||||
spec/frontend/sidebar/components/milestone/milestone_dropdown_spec.js
|
||||
spec/frontend/sidebar/components/subscriptions/subscriptions_dropdown_spec.js
|
||||
spec/frontend/super_sidebar/components/sidebar_portal_spec.js
|
||||
spec/frontend/super_sidebar/components/user_menu_spec.js
|
||||
spec/frontend/tooltips/index_spec.js
|
||||
spec/frontend/vue_alerts_spec.js
|
||||
spec/frontend/vue_popovers_spec.js
|
||||
spec/frontend/vue_shared/components/confirm_modal_spec.js
|
||||
spec/frontend/vue_shared/components/design_management/design_note_pin_spec.js
|
||||
spec/frontend/vue_shared/components/file_tree_spec.js
|
||||
spec/frontend/vue_shared/components/filtered_search_bar/tokens/date_token_spec.js
|
||||
|
|
|
|||
|
|
@ -80,9 +80,7 @@ describe('UserProfileSetStatusWrapper', () => {
|
|||
|
||||
await nextTick();
|
||||
|
||||
expect(
|
||||
findInput(defaultProvide.fields.clearStatusAfter.name).attributes('value'),
|
||||
).toBeUndefined();
|
||||
expect(findInput(defaultProvide.fields.clearStatusAfter.name).element.value).toBe('');
|
||||
});
|
||||
});
|
||||
|
||||
|
|
|
|||
|
|
@ -35,11 +35,9 @@ describe('MilestoneDropdown component', () => {
|
|||
it('renders hidden input', () => {
|
||||
createComponent();
|
||||
|
||||
expect(findHiddenInput().attributes()).toEqual({
|
||||
type: 'hidden',
|
||||
name: 'update[milestone_id]',
|
||||
value: undefined,
|
||||
});
|
||||
expect(findHiddenInput().attributes('type')).toBe('hidden');
|
||||
expect(findHiddenInput().attributes('name')).toBe('update[milestone_id]');
|
||||
expect(findHiddenInput().element.value).toBe('');
|
||||
});
|
||||
|
||||
describe('when milestone ID and title is provided', () => {
|
||||
|
|
|
|||
|
|
@ -53,7 +53,7 @@ describe('vue_shared/components/confirm_modal', () => {
|
|||
const findFormData = () =>
|
||||
findForm()
|
||||
.findAll('input')
|
||||
.wrappers.map((x) => ({ name: x.attributes('name'), value: x.attributes('value') }));
|
||||
.wrappers.map((x) => ({ name: x.attributes('name'), value: x.element.value }));
|
||||
const findDomElementListener = () => wrapper.findComponent(DomElementListener);
|
||||
const triggerOpenWithEventHub = (modalData) => {
|
||||
eventHub.$emit(EVENT_OPEN_CONFIRM_MODAL, modalData);
|
||||
|
|
@ -83,7 +83,7 @@ describe('vue_shared/components/confirm_modal', () => {
|
|||
it('renders form missing values', () => {
|
||||
expect(findForm().attributes('action')).toBe('');
|
||||
expect(findFormData()).toEqual([
|
||||
{ name: '_method', value: undefined },
|
||||
{ name: '_method', value: '' },
|
||||
{ name: 'authenticity_token', value: 'test-csrf-token' },
|
||||
]);
|
||||
});
|
||||
|
|
|
|||
|
|
@ -5625,10 +5625,12 @@ RSpec.describe User, feature_category: :user_profile do
|
|||
end
|
||||
|
||||
shared_examples 'project member' do
|
||||
before do
|
||||
add_user # this method has to be defined in the caller block
|
||||
end
|
||||
|
||||
context 'when the user is a maintainer' do
|
||||
before do
|
||||
project.add_maintainer(user)
|
||||
end
|
||||
let(:access) { :maintainer }
|
||||
|
||||
it 'loads the runners of the project' do
|
||||
expect(user.ci_owned_runners).to contain_exactly(project_runner)
|
||||
|
|
@ -5640,9 +5642,7 @@ RSpec.describe User, feature_category: :user_profile do
|
|||
end
|
||||
|
||||
context 'when the user is a developer' do
|
||||
before do
|
||||
project.add_developer(user)
|
||||
end
|
||||
let(:access) { :developer }
|
||||
|
||||
it 'does not load any runner' do
|
||||
expect(user.ci_owned_runners).to be_empty
|
||||
|
|
@ -5654,9 +5654,7 @@ RSpec.describe User, feature_category: :user_profile do
|
|||
end
|
||||
|
||||
context 'when the user is a reporter' do
|
||||
before do
|
||||
project.add_reporter(user)
|
||||
end
|
||||
let(:access) { :reporter }
|
||||
|
||||
it 'does not load any runner' do
|
||||
expect(user.ci_owned_runners).to be_empty
|
||||
|
|
@ -5668,9 +5666,7 @@ RSpec.describe User, feature_category: :user_profile do
|
|||
end
|
||||
|
||||
context 'when the user is a guest' do
|
||||
before do
|
||||
project.add_guest(user)
|
||||
end
|
||||
let(:access) { :guest }
|
||||
|
||||
it 'does not load any runner' do
|
||||
expect(user.ci_owned_runners).to be_empty
|
||||
|
|
@ -5847,8 +5843,128 @@ RSpec.describe User, feature_category: :user_profile do
|
|||
context 'when user is member of project' do
|
||||
let(:project_runner) { runner }
|
||||
|
||||
def add_user
|
||||
project.add_member(user, access)
|
||||
end
|
||||
|
||||
it_behaves_like 'project member'
|
||||
end
|
||||
|
||||
context 'when group member accesses project runner' do
|
||||
let_it_be(:group) { create(:group) }
|
||||
|
||||
it_behaves_like 'group member'
|
||||
|
||||
context "when user's group is invited to project" do
|
||||
let(:project_runner) { runner }
|
||||
|
||||
def add_user
|
||||
group.add_member(user, access)
|
||||
create(:project_group_link, access, group: group, project: project)
|
||||
end
|
||||
|
||||
it_behaves_like 'project member'
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
context 'when optimize_ci_owned_project_runners_query feature flag is disabled' do
|
||||
before do
|
||||
stub_feature_flags(optimize_ci_owned_project_runners_query: false)
|
||||
end
|
||||
|
||||
it 'returns results from project_members, group_members and group_runners methods' do
|
||||
expect(user).to receive_messages(ci_owned_project_runners_from_project_members: [],
|
||||
ci_owned_project_runners_from_group_members: [],
|
||||
ci_owned_group_runners: []
|
||||
)
|
||||
expect(user).not_to receive(:ci_owned_project_runners)
|
||||
|
||||
user.ci_owned_runners
|
||||
end
|
||||
end
|
||||
|
||||
context 'feature flag behavior' do
|
||||
let(:ff_user) { user }
|
||||
|
||||
before do
|
||||
stub_feature_flags(optimize_ci_owned_project_runners_query: ff_user)
|
||||
end
|
||||
|
||||
it 'respects feature flag scoped to user' do
|
||||
expect(user).to receive(:ci_owned_project_runners).and_return([])
|
||||
expect(user).to receive(:ci_owned_group_runners).and_return([])
|
||||
expect(user).not_to receive(:ci_owned_project_runners_from_project_members)
|
||||
expect(user).not_to receive(:ci_owned_project_runners_from_group_members)
|
||||
|
||||
user.ci_owned_runners
|
||||
end
|
||||
|
||||
context 'when feature flag is only enabled for other user' do
|
||||
let(:ff_user) { build(:user, id: 1) }
|
||||
|
||||
it 'uses old behavior' do
|
||||
expect(user).to receive(:ci_owned_project_runners_from_project_members).and_return([])
|
||||
expect(user).to receive(:ci_owned_project_runners_from_group_members).and_return([])
|
||||
expect(user).to receive(:ci_owned_group_runners).and_return([])
|
||||
|
||||
user.ci_owned_runners
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
describe '#ci_owned_project_runners', feature_category: :runner do
|
||||
let_it_be_with_refind(:user) { create(:user) }
|
||||
|
||||
let_it_be(:project1) { create(:project) }
|
||||
let_it_be(:project2) { create(:project) }
|
||||
let_it_be(:project3) { create(:project) } # no access to project 3
|
||||
|
||||
let_it_be(:runner1) { create(:ci_runner, :project, projects: [project1]) }
|
||||
let_it_be(:runner2) { create(:ci_runner, :project, projects: [project2]) }
|
||||
let_it_be(:runner3) { create(:ci_runner, :project, projects: [project3]) }
|
||||
|
||||
subject(:ci_owned_project_runners) { user.send :ci_owned_project_runners }
|
||||
|
||||
context 'when the user has maintainer access' do
|
||||
before_all do
|
||||
project1.add_maintainer(user)
|
||||
project2.add_maintainer(user)
|
||||
end
|
||||
|
||||
it { is_expected.to include(runner1, runner2) }
|
||||
it { is_expected.not_to include(runner3) }
|
||||
end
|
||||
|
||||
context 'when the user has developer level access in the project' do
|
||||
before_all do
|
||||
project3.add_developer(user)
|
||||
end
|
||||
|
||||
it { is_expected.not_to include(runner3) }
|
||||
end
|
||||
|
||||
context 'with no project authorizations' do
|
||||
it { is_expected.to be_empty }
|
||||
end
|
||||
|
||||
context 'it tracks an internal event' do
|
||||
let!(:project_size) { 100 }
|
||||
|
||||
before do
|
||||
allow(user.project_authorizations).to receive_message_chain(:where, :pluck)
|
||||
.and_return(Array.new(project_size) { |i| i + 1 })
|
||||
end
|
||||
|
||||
it 'with size of project_ids' do
|
||||
expect { ci_owned_project_runners }.to trigger_internal_events('query_ci_owned_project_runners_with_project_ids').with(
|
||||
user: user,
|
||||
additional_properties: {
|
||||
value: project_size
|
||||
}
|
||||
)
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
|
|
|
|||
|
|
@ -11,6 +11,15 @@ RSpec.describe API::Namespaces, :aggregate_failures, feature_category: :groups_a
|
|||
let_it_be(:project_namespace) { project.project_namespace }
|
||||
let_it_be(:path) { "/namespaces" }
|
||||
|
||||
shared_examples "returns empty results" do
|
||||
it "returns empty array" do
|
||||
expect(response).to have_gitlab_http_status(:ok)
|
||||
expect(response).to include_pagination_headers
|
||||
expect(json_response).to be_an Array
|
||||
expect(json_response.length).to eq(0)
|
||||
end
|
||||
end
|
||||
|
||||
describe "GET /namespaces" do
|
||||
context "when unauthenticated" do
|
||||
it "returns authentication error" do
|
||||
|
|
@ -123,6 +132,69 @@ RSpec.describe API::Namespaces, :aggregate_failures, feature_category: :groups_a
|
|||
end
|
||||
end
|
||||
end
|
||||
|
||||
describe 'full_path_search' do
|
||||
let_it_be(:subgroup) { create(:group, parent: group1, owners: [user]) }
|
||||
|
||||
before do
|
||||
get api("/namespaces?search=#{search}&full_path_search=#{full_path_search}", user)
|
||||
end
|
||||
|
||||
context 'when true' do
|
||||
let(:full_path_search) { true }
|
||||
|
||||
context 'when search matches full_path' do
|
||||
let(:search) { subgroup.full_path }
|
||||
|
||||
it 'returns an array of matched namespaces by full_path' do
|
||||
expect(response).to have_gitlab_http_status(:ok)
|
||||
expect(response).to include_pagination_headers
|
||||
expect(json_response).to be_an Array
|
||||
expect(json_response.length).to eq(1)
|
||||
expect(json_response.last['path']).to eq(subgroup.path)
|
||||
expect(json_response.last['full_path']).to eq(subgroup.full_path)
|
||||
end
|
||||
end
|
||||
|
||||
context 'when search does not match full_path' do
|
||||
let(:search) { 'non_existent_group' }
|
||||
|
||||
it_behaves_like "returns empty results"
|
||||
end
|
||||
end
|
||||
|
||||
context 'when false' do
|
||||
let(:full_path_search) { false }
|
||||
|
||||
context 'when search matches full_path' do
|
||||
let(:search) { subgroup.full_path }
|
||||
|
||||
it_behaves_like "returns empty results"
|
||||
end
|
||||
|
||||
context 'when search does not match full_path' do
|
||||
let(:search) { 'non_existing_group' }
|
||||
|
||||
it_behaves_like "returns empty results"
|
||||
end
|
||||
end
|
||||
|
||||
context 'when nil' do
|
||||
let(:full_path_search) { nil }
|
||||
|
||||
context 'when search matches full_path' do
|
||||
let(:search) { subgroup.full_path }
|
||||
|
||||
it_behaves_like "returns empty results"
|
||||
end
|
||||
|
||||
context 'when search does not match full_path' do
|
||||
let(:search) { 'non_existent_group' }
|
||||
|
||||
it_behaves_like "returns empty results"
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
describe 'GET /namespaces/:id' do
|
||||
|
|
|
|||
|
|
@ -165,4 +165,5 @@
|
|||
- :without_license
|
||||
- :yaml_processor_feature_flag_corectness
|
||||
- :zoekt
|
||||
- :zoekt_cache_disabled
|
||||
- :zoekt_settings_enabled
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ module Tooling
|
|||
MSG
|
||||
|
||||
PII_WARNING = <<~MSG
|
||||
Make sure the additional properties don't contain any sensitive information, like customer data or PII.
|
||||
Make sure the additional properties don't contain any sensitive information, like customer data or personal data.
|
||||
For more information, see the Data Classification Standard at https://about.gitlab.com/handbook/security/data-classification-standard/
|
||||
MSG
|
||||
|
||||
|
|
|
|||
|
|
@ -159,7 +159,7 @@ module Tooling
|
|||
# @param strategy [Symbol]
|
||||
# @return [Hash]
|
||||
def generate_metrics_data(changed_files, predicted_test_files, failed_test_files, crystalball_mapping, strategy)
|
||||
all_test_files_from_mapping = crystalball_mapping.values.flatten
|
||||
all_test_files_from_mapping = crystalball_mapping.values.flatten.uniq
|
||||
test_files_selected_by_crystalball = changed_files
|
||||
.filter_map { |file| crystalball_mapping[file] }
|
||||
.flatten
|
||||
|
|
|
|||
Loading…
Reference in New Issue