Enabling GitLab pages access control is still broken resulting in pages going to private unexpectedly

Summary

Original issue at gitlab-foss#59286 (closed) still exists. 2 years after introduction, this migration bug still prevents me from using this feature.

After enabling access control feature via gitlab_pages['access_control'] = true existing GitLab pages sites will incorrectly have access controls set to private on next save of project settings.

Steps to reproduce

  1. GitLab instances with pages access levels never having been enabled. Set custom gitlab_rails['shared_path'] = '/data (no idea if this makes a difference)
  2. Create private GitLab project and publish GitLab pages site from it
  3. Verify can access site without authentication
  4. Enable via gitlab_pages['access_control'] = true
  5. Access GitLab pages site, still loads ✔
  6. Look at project settings page - we can see it says it shouldn't load? ❌ That's not expected migration (public page should not become private without user action) nor is it accurate - we just viewed page without authentication even though it says it should be required image
  7. Without changing anything, select save on project settings page
    • Why is the save button even showing as active? We didn't change anything...
  8. Now the site cannot be loaded without authentication. We didn't change any options, this should not require authentication... ❌

Example Project

n/a

What is the current bug behavior?

After enabling access control feature publicly accessible GitLab pages sites are being changed to private unexpectedly upon user saving project settings without explicitly setting to to private

What is the expected correct behavior?

When GitLab pages access control is enabled, existing sites should have setting site to allow "Everyone" which is equivalent to GitLab pages without access controls enabled

Relevant logs and/or screenshots

above

Output of checks

n/a

Results of GitLab environment info

12.10 omnibus

Results of GitLab application Check

all good

Proposed solution

  • Change access level for pages to public when pages are deployed if access control is disabled on the instance level
  • Rewrite old migration using pages_metadata and re-apply it for fix problem for existing instances

Workaround

#230584 (comment 405101626)

Edited by Ben Bodenmiller