GitLab Pages migration feedback
If you see a problem with GitLab Pages upgrading to 14.*
- Read this issue and the discussions below. We fixed most common bugs in 14.1 and 14.3. So upgrading to 14.3 should help.
- If upgrade to 14.3 doesn't help, and you can't find a solution in this issue, please open a new issue in https://gitlab.com/gitlab-org/gitlab-pages/-/issues. You can ping @vshushlin and @jaime, so we can see that issue quicker.
This issue is now closed as we resolved most of feedback But you can reopen it if you think it's necessary.
In &1316 (closed) we introduced a number of architectural changes to GitLab Pages.
Starting from %14.0 defaults change:
- we stop using
config.jsonfiles inshared/pagesas the source of information and switch to API. This means that the GitLab instance should be accessible from the GitLab Pages server, API should be properly configured and secrets should be synced. - we stop serving from files located in
shared/pagesdirectory, so they should be migrated to new ZIP-storage. For most users this will happen automatically when they migrate to13.12or above, but the migration process happens in background and it's intentionally slow to avoid performance impact on the GitLab server.
You can read more about the migration process here.
Both changes can be temporary reversed by using use_legacy_storage flag. If you need to use this flag, please comment on this issue describing the problem you see. This flag is a temporary solution to give users a fallback for any unforeseen problems, it will be removed in %14.3.
Also, please ping @vshushlin or @jaime when commenting(we'll see your comments faster this way
If you use inplace_chroot=true
Please follow these instructions.
UPDATE: 2021-07-14:
The chroot will be disabled for API-based configuration starting from GitLab 14.1 gitlab-pages#589 (closed) and Pages 1.41.0 for source installations.
Please remove use_legacy_storage and report any issues here
Update 2021-07-26
As of GitLab 14.1 gitlab_pages['inplace_chroot'] is no longer necessary and gitlab_pages['access_control']=true can be enabled as well.
If you have enabled use_legacy_storage you should be able to disable this along with inplace_chroot.
You can find a sample of a working configuration here
Demo https://youtu.be/nLC5KjrZ-q8
What are we currently working on
-
gitlab-pages!513 (merged) to disable chroot and will be hopefully released in %14.1
✅ - Found issue gitlab-pages#587 (closed) which will allow subpaths to be used in
gitlab_server/internal_gitlab_server✅
What will happen on or after 14.3?
-
use_legacy_storagewill be removed omnibus-gitlab#6166 (closed) - The
chrootmechanism will be removed from the Pages daemon, DNS resolution is expected to be fixed then gitlab-pages#561 (closed)