To ensure the security of our infrastructure, on Tuesday, February 28th, 2023 GitHub Pages sites that contain symbolic links will no longer build outside of GitHub Actions.
The majority of Pages sites will not be affected by this change since building with GitHub Actions is the default. If any of your Pages sites is affected, you will receive a build failure email with instructions how to fix the error on your next build.
Today we are deprecating the theme picker we introduced in 2012 for GitHub Pages.
While this experience allowed users to preview a theme in the user interface, we are doing this to increase the security of github.com.
You can of course continue to use any Jekyll theme you want with Pages, and publish beautiful sites with a small configuration change.
GitHub Pages now builds with GitHub Actions by default across all repositories.
For more details, see this blog post.
You can now deploy to a GitHub Pages site directly from a repository using GitHub Actions, without needing to set up a publishing source. Using Actions to orchestrate Pages publishing provides many more options for choosing your authoring framework (Next.js, Hugo, Gatsby, Jekyll, NuxtJS or other technologies, and the associated versions thereof) as well as giving you finer control over the publishing process, such as leveraging deployment gates.
We have written several starter workflows for the most common frameworks but also have a “Static“ option if you want to deploy the contents of your repository with no build step.
Resources:
Today you will begin to see a new workflow running called pages build and deployment in your public GitHub Pages repositories. This workflow is automatically triggered when you push to the branch configured for GitHub Pages in your repository. As the name suggests, it builds and deploys your pages site. The initial benefit of this change is enabling you to see your build logs and any errors that may occur which has been a long standing issue for Pages users. However, in the future this will enable us to give you the ability to fully customize your pages build and deployment workflow to use any static site generator you want without having to push the build output to a special branch of the repository.
You may notice this workflow uses some new actions actions/pages-deploy, and actions/jekyll-build-pages. For now these actions are designed to be used in the generated workflow, however, starting early next year we will introduce some additional changes that will enable you to take advantage of them.
Users and organizations can now verify GitHub Pages domains to protect against takeover attacks.
Learn more about verifying your custom domain for GitHub Pages
When configuring a custom domain for your GitHub Pages site, we will now automatically request a certificate for both the Apex and www subdomain of that custom domain if DNS is configured appropriately. As part of this, we've also moved the GitHub Pages settings to their own dedicated tab and refreshed the setup flow to help you get everything set up with ease.
If you don't want to use both domains with GitHub Pages, we'll continue requesting a certificate for only the specific domain you configure. Custom domains that use a subdomain other than www are not affected by this change.
Beginning April 15, 2021, we will stop redirecting GitHub Pages sites from *.github.com to the *.github.io domain.
Today, we serve all GitHub Pages sites from the *.github.io domain, but before 2013 we used the *.github.com domain. On April 5, 2013, we deprecated the *.github.com domain for the Pages sites and started redirecting all traffic to the new location. After April 15, 2021, we will stop doing this redirection. We are taking this action to further protect github.com overall.
How does this affect me?
If you’ve configured a custom domain for your Pages site or you directly access your site on *.github.io, you will not be affected by this change. If, however, your site still receives traffic through a redirect from *.github.com, after April 15, 2021 that URL will stop working.
To ensure all affected customers are aware of this change, during two scheduled brownouts, we will temporarily suspend redirection of Pages sites from *.github.com. The brownouts are scheduled for the following dates and times:
What actions should I take?
We strongly recommend that you remove any external references to *.github.com to avoid any traffic loss to your Pages sites. Additionally, we recommend that you should review your site's dependencies to check for resources that may have been hosted on Pages sites that expected a *.github.com URL. In most cases, simply updating those dependencies to use *.github.io will ensure they continue to work after April 15th.
Please contact support if you experience any issues due to these changes.
GitHub Pages now gives you the option to limit access, making the site visible only to users with access to the repository that published the Page. With access control, you can use GitHub Pages to publish and share internal documentation and knowledge across your enterprise.
As part of this release, we are introducing the following capabilities:
This feature is generally available today on GitHub Enterprise Cloud. To enable access control on Pages, navigate to your repository settings, and click the dropdown menu to toggle between public and private visibility for your site.
Organization owners can now disable publication of GitHub Pages sites from repositories in the organization. Disabling GitHub Pages for the organization will prevent members from creating new Pages sites but will not unpublish existing sites.
You can learn more about this new setting in our documentation.
Repositories that use GitHub Pages can now build and deploy from any branch. Publishing to the special gh-pages branch will still work the same as it always has, but you can now choose a different branch in your repository as the publishing source. This functionality also removes the hardcoded dependency on user and organization pages having a master branch.
Repositories that use GitHub Pages can now build and deploy from any branch. Publishing to the special gh-pages branch will still work the same as it always has, but you can now choose a different branch in your repository as the publishing source. This functionality also removes the hardcoded dependency on user and organization pages having a master branch.
