Dependency Proxy variables still available when disabled

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Summary

The variables for Dependency Proxy are still available, even it has been configured to be disabled at group level.

Steps to reproduce

  1. Create a group (dependency proxy is enabled by default)
  2. Create a project
  3. Push a CI pipeline with script that references variables relates to dependency proxy
  4. Disable dependency proxy at group level. Wait until it shows Settings saved successfully. at the bottom left of the page.
  5. Manually trigger the same pipeline by clicking "New Pipeline" for the primary branch

This is reproducible in both GitLab.com and self-managed GitLab instance.

Implementation Plan

Objective: Ensure CI variables for Dependency Proxy are only populated when the feature is enabled at both instance and group levels.

Changes needed:

  1. Update Project#dependency_proxy_variables (app/models/project.rb):
    • Add check for group-level dependency_proxy_enabled setting
    • Only populate variables when both instance-level AND group-level settings are enabled
  2. Testing:
    • Add specs for variable population with various combinations:
      • Instance enabled, group enabled → variables present
      • Instance enabled, group disabled → variables empty
      • Instance disabled, group enabled → variables empty
      • Instance disabled, group disabled → variables empty
  3. Documentation:
    • Update CI/CD variables documentation to clarify when Dependency Proxy variables are available

Acceptance criteria:

  • CI variables are empty when Dependency Proxy is disabled at group level
  • Existing functionality preserved when Dependency Proxy is enabled
  • Test coverage for all scenarios

Example Project

I've created a simple test project: https://gitlab.com/jackyccc-test-group/dependency-proxy-test

Where:

$ echo CI_DEPENDENCY_PROXY_SERVER=$CI_DEPENDENCY_PROXY_SERVER
CI_DEPENDENCY_PROXY_SERVER=gitlab.com:443
$ echo CI_DEPENDENCY_PROXY_USER=$CI_DEPENDENCY_PROXY_USER
CI_DEPENDENCY_PROXY_USER=gitlab-ci-token
$ echo CI_DEPENDENCY_PROXY_DIRECT_GROUP_IMAGE_PREFIX=$CI_DEPENDENCY_PROXY_DIRECT_GROUP_IMAGE_PREFIX
CI_DEPENDENCY_PROXY_DIRECT_GROUP_IMAGE_PREFIX=gitlab.com:443/jackyccc-test-group/dependency_proxy/containers
$ echo CI_DEPENDENCY_PROXY_SERVER=$CI_DEPENDENCY_PROXY_SERVER
CI_DEPENDENCY_PROXY_SERVER=gitlab.com:443
$ echo CI_DEPENDENCY_PROXY_USER=$CI_DEPENDENCY_PROXY_USER
CI_DEPENDENCY_PROXY_USER=gitlab-ci-token
$ echo CI_DEPENDENCY_PROXY_DIRECT_GROUP_IMAGE_PREFIX=$CI_DEPENDENCY_PROXY_DIRECT_GROUP_IMAGE_PREFIX
CI_DEPENDENCY_PROXY_DIRECT_GROUP_IMAGE_PREFIX=gitlab.com:443/jackyccc-test-group/dependency_proxy/containers

What is the current bug behavior?

Variables related to Dependency Proxy are still populated.

What is the expected correct behavior?

Variables related to Dependency Proxy should be empty if Dependency Proxy is disabled.

Relevant logs and/or screenshots

Output of checks

This bug happens on GitLab.com

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`)


System information
System:		Debian 13
Proxy:		no
Current User:	git
Using RVM:	no
Ruby Version:	3.2.8
Gem Version:	3.7.1
Bundler Version:2.7.1
Rake Version:	13.0.6
Redis Version:	7.2.11
Sidekiq Version:7.3.9
Go Version:	unknown

GitLab information
Version:	18.8.2-eegitlab-org/gitlab/-/issues/587770
Revision:	75b6aa72896
Directory:	/opt/gitlab/embedded/service/gitlab-rails
DB Adapter:	PostgreSQL
DB Version:	16.11
URL:		https://gitlab.
HTTP Clone URL:	https://gitlab./some-group/some-project.git
SSH Clone URL:	git@gitlab.:some-group/some-project.git
Elasticsearch:	no
Geo:		no
Using LDAP:	no
Using Omniauth:	yes
Omniauth Providers: 

GitLab Shell
Version:	14.45.5
Repository storages:
- default: 	unix:/var/opt/gitlab/gitaly/gitaly.socket
GitLab Shell path:		/opt/gitlab/embedded/service/gitlab-shell

Gitaly
- default Address: 	unix:/var/opt/gitlab/gitaly/gitaly.socket
- default Version: 	18.8.2
- default Git Version: 	2.52.GIT

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)


Checking GitLab subtasks ...


Checking GitLab Shell ...


GitLab Shell: ... GitLab Shell version >= 14.45.5 ? ... OK (14.45.5)
Running /opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell-check
Internal API available: OK
Redis available via internal API: OK
gitlab-shell self-check successful


Checking GitLab Shell ... Finished


Checking Gitaly ...


Gitaly: ... default ... OK


Checking Gitaly ... Finished


Checking Sidekiq ...


Sidekiq: ... Running? ... yes
Number of Sidekiq processes (cluster/worker) ... 1/1


Checking Sidekiq ... Finished


Checking Incoming Email ...


Incoming Email: ... Reply by email is disabled in config/gitlab.yml


Checking Incoming Email ... Finished


Checking LDAP ...


LDAP: ... LDAP is disabled in config/gitlab.yml


Checking LDAP ... Finished


Checking GitLab App ...


Database config exists? ... yes
Tables are truncated? ... skipped
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Cable config exists? ... yes
Resque config exists? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... yes
Systemd unit files or init script exist? ... skipped (omnibus-gitlab has neither init script nor systemd units)
Systemd unit files or init script up-to-date? ... skipped (omnibus-gitlab has neither init script nor systemd units)
Projects have namespace: ...
2/1 ... yes
5/16 ... yes
5/17 ... yes
5/18 ... yes
5/19 ... yes
5/20 ... yes
128/21 ... yes
5/22 ... yes
5/23 ... yes
5/24 ... yes
5/25 ... yes
5/26 ... yes
5/27 ... yes
5/28 ... yes
5/29 ... yes
5/30 ... yes
5/31 ... yes
5/32 ... yes
5/33 ... yes
5/34 ... yes
4/35 ... yes
5/36 ... yes
39/38 ... yes
5/40 ... yes
5/41 ... yes
5/42 ... yes
5/43 ... yes
5/44 ... yes
5/45 ... yes
4/56 ... yes
39/60 ... yes
4/61 ... yes
5/62 ... yes
4/63 ... yes
5/64 ... yes
5/65 ... yes
5/66 ... yes
5/68 ... yes
5/70 ... yes
5/71 ... yes
4/72 ... yes
5/73 ... yes
5/74 ... yes
5/75 ... yes
5/76 ... yes
5/77 ... yes
5/78 ... yes
5/79 ... yes
5/80 ... yes
122/81 ... yes
128/82 ... yes
5/85 ... yes
132/86 ... yes
131/87 ... yes
140/90 ... yes
131/91 ... yes
143/92 ... yes
131/93 ... yes
131/94 ... yes
124/95 ... yes
128/96 ... yes
131/97 ... yes
130/98 ... yes
131/99 ... yes
131/100 ... yes
128/101 ... yes
224/102 ... yes
131/103 ... yes
44/104 ... yes
143/105 ... yes
139/106 ... yes
139/107 ... yes
131/108 ... yes
130/109 ... yes
122/110 ... yes
5/111 ... yes
5/112 ... yes
214/113 ... yes
5/114 ... yes
139/115 ... yes
122/116 ... yes
5/117 ... yes
140/118 ... yes
130/121 ... yes
130/122 ... yes
130/123 ... yes
130/124 ... yes
5/125 ... yes
131/127 ... yes
193/128 ... yes
131/129 ... yes
197/130 ... yes
131/131 ... yes
131/132 ... yes
128/133 ... yes
214/134 ... yes
214/135 ... yes
214/136 ... yes
214/137 ... yes
214/138 ... yes
214/139 ... yes
131/140 ... yes
143/141 ... yes
131/142 ... yes
217/143 ... yes
219/144 ... yes
131/145 ... yes
131/146 ... yes
131/147 ... yes
224/148 ... yes
5/149 ... yes
131/150 ... yes
139/151 ... yes
5/152 ... yes
131/153 ... yes
139/154 ... yes
5/155 ... yes
139/156 ... yes
139/157 ... yes
5/158 ... yes
237/159 ... yes
131/160 ... yes
131/161 ... yes
143/162 ... yes
237/164 ... yes
237/165 ... yes
131/166 ... yes
143/167 ... yes
131/168 ... yes
131/169 ... yes
131/170 ... yes
131/171 ... yes
256/172 ... yes
193/173 ... yes
193/174 ... yes
256/175 ... yes
261/176 ... yes
5/177 ... yes
267/180 ... yes
267/181 ... yes
267/182 ... yes
267/183 ... yes
267/186 ... yes
131/187 ... yes
128/188 ... yes
131/189 ... yes
131/190 ... yes
131/191 ... yes
131/192 ... yes
139/193 ... yes
131/194 ... yes
131/195 ... yes
131/196 ... yes
139/197 ... yes
131/198 ... yes
131/199 ... yes
131/200 ... yes
5/201 ... yes
299/202 ... yes
5/203 ... yes
299/204 ... yes
5/205 ... yes
5/206 ... yes
5/207 ... yes
5/208 ... yes
309/209 ... yes
291/210 ... yes
267/211 ... yes
313/212 ... yes
131/213 ... yes
139/214 ... yes
131/215 ... yes
131/216 ... yes
131/217 ... yes
131/218 ... yes
214/221 ... yes
214/222 ... yes
325/223 ... yes
131/224 ... yes
362/225 ... yes
334/227 ... yes
336/228 ... yes
5/229 ... yes
339/230 ... yes
341/231 ... yes
346/233 ... yes
348/234 ... yes
348/235 ... yes
348/236 ... yes
348/237 ... yes
348/238 ... yes
348/239 ... yes
348/240 ... yes
356/241 ... yes
4/242 ... yes
4/244 ... yes
193/245 ... yes
348/246 ... yes
348/247 ... yes
348/248 ... yes
4/249 ... yes
367/250 ... yes
370/251 ... yes
131/252 ... yes
373/253 ... yes
Redis version >= 6.2.14? ... yes
Ruby version >= 3.0.6 ? ... yes (3.2.8)
Git user has default SSH configuration? ... yes
Active users: ... 21
Is authorized keys file accessible? ... yes
GitLab configured to store new projects in hashed storage? ... yes
All projects are in hashed storage? ... yes
Elasticsearch version 7.x-9.x or OpenSearch version 1.x-3.x ... skipped (advanced search is disabled)
All migrations must be finished before doing a major upgrade ... skipped (Advanced Search is disabled)


Checking GitLab App ... Finished


Checking GitLab subtasks ... Finished

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.

Relates to components/opentofu#211

Edited by 🤖 GitLab Bot 🤖