Skip to content

Draft: Protected packages: Use positive logic to protected_up_to_access_level

Gerardo Navarro requested to merge gitlab-community/gitlab:416382-gerardo-navarro-protected-packages-basics-for-protecting-packages-renmaing-access-level-related-attributes into master

What does this MR do and why?

  • As discussed in a previous MR discussion, we see the need to rename the fields push_protected_up_to_access_level in order to apply a positive logic (instead of negative logic)
    • Field push_protected_up_to_access_level is renamed to field minimum_access_level_for_push
  • But, when renaming these fields, we also need to change the logic and values of the fields => hence, we need to also migrate the data; the following mapping describes the mapping, e.g. when the field push_protected_up_to_access_level is set to the access level :developer (meaning that a certain package is push protected up to the access level :developer) then we will need to set the access level to :maintainer for the field minimum_access_level_for_push (because the access level :maintainer is the lowest access level that is allowed to push a certain package).
push_protected_up_to_access_level minimum_access_level_for_push
:developer :maintainer
:maintainer :owner
:owner :admin

🛠 with ❤ at Siemens

Open Questions

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

MR Checklist (@gerardo-navarro)

DB queries

As part of the migration, the following SQL query is used.

UPDATE "packages_protection_rules" SET "minimum_access_level_for_push" = 60 WHERE "packages_protection_rules"."push_protected_up_to_access_level" = 50

Screenshots or screen recordings

No frontend changes. This MR contains primarily changes in the backend .

How to set up and validate locally

  1. Migrate your local database
rails db:migrate
  1. Enable feature flag via rails c 
Feature.enable(:packages_protected_packages)
  1. Open the rails console (rails c) and start playing around with the new model
Packages::Protection::Rule.create(
  project: Project.find_by(name: "Flight"),
  package_name_pattern: "@flightjs/test-npm-package-*",
  package_type: :npm,
  minimum_access_level_for_push: :admin
)
  1. Create a dummy project for npm package for testing publishing
# Go to a directory outside of the gitlab and gdk directory
mkdir test-npm-package && cd test-npm-package
npm init esm --yes
  1. Adjust the package name in package.json and set it to "@flightjs/test-npm-package-prod" <= this should match the given package_name_pattern in step 3
  2. Create or adjust file .npmrc in order to push the npm package to the GitLab registry, see https://docs.gitlab.com/ee/user/packages/npm_registry/#authenticating-via-the-npmrc
  3. Publish npm test package
NPM_TOKEN=ypCa3Dzb23o5nvsixwPA npm publish
  1. Pushing the package should be blocked by the Packages::Protection::Rule because you the user (with NPM_TOKEN) is a project owner and the package "@flightjs/test-npm-package-prod" can only be modified by an :admin user role 💥
  2. Now, change the package name in package.json and set it to "@flightjs/test-npm-package2-prod" <= this will not match the given package_name_pattern in step 3
  3. Now, try again to publish the npm package
NPM_TOKEN=ypCa3Dzb23o5nvsixwPA npm publish
  1. Pushing the npm package should not be blocked by the Packages::Protection::Rule as the package name does not match 👍
  2. You can also change the value of the field minimum_access_level_for_push to :owner and then it is possible to push all kind of packages 👍

Related to #416382

Edited by Gerardo Navarro

Merge request reports