GitLab Pages blocks access to site, even when authentication is disabled
The recent rebuild of review to test apps #41 (closed) has lead to a regression in page deployment of the site at https://next.ecobytes.net
We enacted an undocumented requirement and restricted access to the website to authenticated users of this GitLab that are members of this repository. As it turns out, the GitLab Pages support for this feature is not very solid, and the page now permanently responds with 404, previously temporarily with 401, despite all lights are green in the piplines, the pages:deploy job and also on the pages settings page. Even a certificate will be deployed as expected.
Further analysis of the situation in #62 (closed) has shown that a path depth error leads to a misplaced build, which also breaks styles. The page remained accessible at https://web-ecobytes-4b2026591591ce32f574688fb6650aeaebe251c6c8de0f2703.pages.allmende.io/dist/ all the time.
–
-
#61 The certificate used for booting up the GitLab Pages daemon—it is only shown on erroring domain configurations as ours here–is provided by an Ecobytes CA and contains helpful contact information -
#62 (closed) Authenticated access to the site https://next.ecobytes.net is restored and continues to be deployed from CI here.