Skip to content

GitHub Pages: using GitHub Actions for builds and deployments for public repositories

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.

Learn more about GitHub Pages

Up until today, the GitHub Advisory Database has only published advisories that have been curated and approved by our Security Lab team.

This approach meant users sometimes couldn't find advisories in our database when searching, so the Advisory Database now has a separate section of listings for unreviewed advisories. These will be auto-published from the National Vulnerability Database feed.

Screenshot of unreviewed advisories

If you search for a term like "WordPress plugin," you can now see listings that are both GitHub reviewed and unreviewed. If you'd like to filter for only reviewed advisories, add type:reviewed to your query. Alternatively, you can also enter your query and then click the "All reviewed" button on the left-hand sidebar.

Screenshot of filtering for reviewed advisories

Dependabot alerts will continue to only be generated for GitHub Reviewed advisories in order to preserve their curated level of quality.

See more

Now, only admins can rename branches that are protected by branch protection rules.

GitHub allows repository collaborators to rename every branch in a repository, with the exception of the default branch.
When a collaborator renames a branch, any non-wildcard branch protection rules that apply to that branch are also changed to match the branch's new name.
Because only admins can modify branch protection rules, renaming of a protected branch is now limited to admin users.

For more information, visit Renaming a branch and Managing a branch protection rule.

See more