Skip to content

Backfill project feature 'package_registry_access_level'

What does this MR do and why?

In !82808 (merged), I implemented a new project setting to set the visibility of the package registry (behind a feature flag). In the process, the old project.packages_enabled property is replaced by the new project_feature.package_registry_access_level property.

This MR is the next step of the implementation plan and adds a background migration to backfill project_feature.package_registry_access_level depending on project.packages_enabled.

The following values are set during migration:

project.packages_enabled project.visibility_level Result: project_feature.package_registry_access_level
true PUBLIC (20) ProjectFeature::PUBLIC (30)
true INTERNAL (10) ProjectFeature::ENABLED (20)
true PRIVATE (0) ProjectFeature::PRIVATE (10)
false PUBLIC (20) ProjectFeature::DISABLED (0)
false INTERNAL (10) ProjectFeature::DISABLED (0)
false PRIVATE (0) ProjectFeature::DISABLED (0)

Implementation plan

🛠 with at Siemens

/cc @bufferoverflow

Database Migration

Up
$ rails db:migrate
main: == 20220602070502 QueueBackfillProjectFeaturePackageRegistryAccessLevel: migrating 
main: -- transaction_open?()
main:    -> 0.0000s
main: == 20220602070502 QueueBackfillProjectFeaturePackageRegistryAccessLevel: migrated (0.1421s) 

ci: == 20220602070502 QueueBackfillProjectFeaturePackageRegistryAccessLevel: migrating 
ci: -- The migration is skipped since it modifies the schemas: [:gitlab_main].
ci: -- This database can only apply migrations in one of the following schemas: [:gitlab_ci, :gitlab_shared].
ci: == 20220602070502 QueueBackfillProjectFeaturePackageRegistryAccessLevel: migrated (0.0002s)
Down
$ rails db:migrate:down:main VERSION=20220602070502
main: == 20220602070502 QueueBackfillProjectFeaturePackageRegistryAccessLevel: reverting 
main: == 20220602070502 QueueBackfillProjectFeaturePackageRegistryAccessLevel: reverted (0.0529s)

How to set up and validate locally

  1. Add some project with different visibility_level and packages_enabled.
  2. Run migration
  3. Rollback migration

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Jonas Wälter

Merge request reports