<rant>
The access level is "Only Project Members" by default for private projects, which I consider a breaking change because the steps I previously used to create public Pages (add .gitlab-ci.yml and push) no longer work.
The first time I tried to deploy Pages after the access control feature was enabled I wasted a lot of time because of this. When my new webpage redirect to the GitLab sign in page, I didn't bother signing in (why should I, when Pages have always been public?). I waited a day, because Pages have taken several hours to provision in the past[1]. Finally I started searching the web for why Pages was redirecting to the sign in page and found out about the access control feature.
I support having the access level "Only Project Members" by default, but I think the rollout could have been done much better. My main objections:
- There was no indication that the new webpage existed and that the issue was access control -- when I tried visiting the webpage for a non-existent project I got the same redirect. I understand why (to avoid leaking the names of private projects), but the redirected sign in page could have still shown a generic message ("project is missing or private") and mentioned that Pages are now private by default.
- The setting was not in an obvious location for me. I checked "Settings > Pages", which said the pages are served but did not give any indication that access control was enabled. There should have been a notice here saying that Pages are now private by default and that this can be changed in "Settings > General > Permissions", at least for the first few months after the rollout.
- The API [2] does not support changing the Pages access level yet, so I have to sign in to GitLab and change it manually (or fake the form submission). I want to be able to create a project with public Pages from the terminal, like I could before.
These issues could have stemmed from an assumption that developers heavily use the GitLab web interface and are always signed in. For me that is not the case.
Some small additional issues:
- The option "Pages access control" in Settings > General > Permissions is badly named because it's not clear what it means when it's toggled off. With the other options (e.g. "Issues", "Wiki", "Snippets") it's clear that toggling off the option removes the feature, but toggling off "Pages access control" could either mean "remove the access control feature" (making the pages available to everyone) or "remove the Pages feature" (making the pages available to no one). From my experiments it appears to be the second.
- The options have a glitch where toggling an option puts the corresponding access level in an inconsistent state. When the "Page access control" option of a private project is toggled off then on, the access level dropdown shows "Only Project Members" as selected but the value of the hidden <input> element is 30 (Everyone). Submitting the form sets the access level to "Everyone", as can be seen when the page refreshes. The other options have the same problem.
</rant>
[1] https://forum.gitlab.com/t/gitlab-pages-404-for-even-the-sim...
[2] https://docs.gitlab.com/ee/api/projects.html#edit-project
https://www.theregister.co.uk/2019/10/16/gitlab_employees_ga...
I prefer a company not ruling their platform by their beliefs but by their countries laws and court rulings.
If the government in question doesn't try to be just, you'll end up assisting murder and silencing the voices of the oppressed.
Sometimes it really is better to say "no" to a business opportunity, if the other side isn't behaving in a sane manner.
And fwiw: gitlab did just that as the sister comment pointed out
[1] https://www.theregister.co.uk/2019/10/17/gitlab_reverse_ferr...
Sure, that policy implies that Gitlab would take China's money if China wanted to be like any other customer. The policy doesn't seem to say whether or not Gitlab would take China's money if that meant censoring their other users.
(Also, that policy was rolled back the next day)
