The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
| Stage | Create |
| Maturity | Complete |
| Content Last Reviewed | 2022-03-10 |
Thanks for visiting this direction page for Pages in GitLab. GitLab Pages allows you to create a statically generated website from your project that is automatically built using GitLab CI and hosted on our infrastructure. This category belongs to the Editor group of the Create stage and the direction page is maintained by Eric Schurter (E-Mail). More information about the Editor group's priorities and direction can be found on the Editor group direction page.
This direction is a work in progress, and everyone can contribute:
Pages is a popular feature and one that people really enjoy engaging with as part of the GitLab experience. Our goal is not to provide a market-leading solution for static web page hosting, but we do want to offer one that is capable for most basic needs, in particular for hosting static content and documentation that is a part of your software release.
Our immediate focus is on improving the stability and security of Pages while addressing our most popular issues and compelling blockers for our users hosting static content and documentation. A bit further down the road we plan to address some of the challenges users face with managing and editing static content.
We are tackling the Object Storage re-architecture to support cloud native installations of GitLab Pages via gitlab#39586. We are working on improvements to pages via Object storage in gitlab&3905 and on transitioning GitLab Pages from NFS to Object Storage in gitlab&3901. The last step that we have for this migration is disconnecting connectivity from NFS in gitlab&4851 which is planned to happen in GitLab 14.0.
This category is currently at the "Complete" maturity level, and our next maturity target is "Lovable" (see our definitions of maturity levels).
Key deliverables to achieve this are:
We are invested in supporting the process of developing and deploying code from a single place as a convenience for our users. Other providers, such as Netlify, deliver a more comprehensive solution. There are project templates available that offer the use of Netlify for static site CI/CD, while also still taking advantage of GitLab for repository, merge requests, issues, and everything else. GitLab offers configurable redirects, a well-loved featured of Netlify, made available in gitlab-pages#24.
We are seeing a rise in JAMStack and static site generators partnering in the media. This trend toward API-first, affirms our modernization effort of Pages, reinforcing our cloud native installation maturity plan.
The most popular customer issue is (gitlab#17584). Creating Gitlab pages today requires admins to setup wildcard DNS records and SSL/TLS certificates. Some services and/or corporate security policies forbid wildcard DNS records, preventing users from benefitting from using Gitlab Pages. This issue will remove the need for wildcard DNS and allow many more users to enjoy the Pages experience.
We are working on better supporting custom domains and will expect to have a path to redirect to custom domains (gitlab#14243) following the Pages re-architecture effort.
Our most popular issue for Pages, Multiple-version Pages support (gitlab#16208) will also need to wait until the new architecture is in place, but we are working on an alternative solution of using environments for achieving the same functionality (gitlab#33822).
Our top internal customer issue is (gitlab#16208) which enables having multiple GitLab Pages generated based on branches or tags. We have been seeing more demand for cloud native, kubernetes based delivery of GitLab.com which GitLab Pages NFS storage is a blocker for, this will be addressed via gitlab#39586.
Adding Review Apps for Pages (gitlab#16907) will allow for more sophisticated development flows involving testing and review of Pages deployments. Enhancing the maturity of deployment would integrate Pages more critically within projects and groups.
The Static Site Editor was conceived as a way to lower the barrier to collaborating on static site content. The WYSIWYG Markdown editing experience introduced as part of the feature's MVC has evolved into a shared editing component that can be used in many places across Gitlab. With the deprecation of the Static Site Editor as a standalone feature, the vision for managing and contributing to static sites in an intuitive and accessible way will be carried forward by the Pages category.
Another vision item being investigated is to leverage JAMstack for Pages. The primary goal would be to enhance the user experience (gitlab#2179) and allow easy to set up Pages from the UI without expanding APIs. Lastly, in combination with feature flags, Pages can be used to support A/B testing (gitlab#14122).