Project feature Package registry impacts ability to clone Internal project with job token

Summary

The default-enabled Project features allows an Internal project to be cloned via the CI/CD job token. This was specifically added to the policies recently: !150763 (merged)

When the project feature "Package Registry" is disabled, the CI/CD job token is no longer able to clone an Internal project. The project needs to be on the CI/CD job token allowlist.

When the project feature "Package Registry" is enabled, the CI/CD job token can be used to clone an Internal project, without the need for the CI/CD job token allowlist.

It doesn't make sense that the Package Registry feature toggle would impact repository cloning.

Steps to reproduce

Seems to occur in versions >= v18.0

  1. Create a top-level group, with two projects: internal and main. internal project must be Internal visibility level.

  2. In main, add internal project as a submodule.

  3. In main, add the CI/CD YAML. replace the PROJECT_NAMESPACE variable with the internal project's namespace.

    clone:
    variables:
      PROJECT_NAMESPACE: "top-level-group/internal"
    script:
        - git clone "https://gitlab-ci-token:${CI_JOB_TOKEN}@${CI_SERVER_URL}/${PROJECT_NAMESPACE}.git"
    when: manual
    
submodule:
    variables:
        GIT_SUBMODULE_STRATEGY: recursive
    script:
        - echo "submodule clone job"

  4. Execute the pipeline. The pipeline job submodule should succeed using the job token, and clone the internal project as a submodule.

  5. Execute the manual job clone in the pipeline. This job should also succeed using the job token.

  6. In the internal project Settings > General, disable the "Package Registry" project feature.

  7. In the Runner, ensure that any Runner build directory information is purged, to force the repo to be cloned again from scratch.

  8. Re-run the pipeline in main project. Also run the manual CI/CD job.

You can also get it working again by:

  1. In the Runner, ensure that any Runner build directory information is purged, to force the repo to be cloned again from scratch.
  2. In internal project Settings > General, enable the "Package Registry" project feature.
  3. Re-run the pipeline in main project. Also run the manual CI/CD job.

Example Project

What is the current bug behavior?

When "Package Registry" project setting is disabled, the CI/CD job token fails to clone the Internal repository.

What is the expected correct behavior?

The "Package Registry" project setting should not affect the CI/CD job token ability to clone the Internal repository.

Relevant logs and/or screenshots

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info 

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check 
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)


(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)


(we will only investigate if the tests are passing)

Possible fixes

Patch release information for backports

If the bug fix needs to be backported in a patch release to a version under the maintenance policy, please follow the steps on the patch release runbook for GitLab engineers.

Refer to the internal "Release Information" dashboard for information about the next patch release, including the targeted versions, expected release date, and current status.

High-severity bug remediation

To remediate high-severity issues requiring an internal release for single-tenant SaaS instances, refer to the internal release process for engineers.

Edited by 🤖 GitLab Bot 🤖