github / roadmap

GitHub public roadmap

GitHub public roadmap

❇️ View the official GitHub public product roadmap¹

Our product roadmap is where you can learn about what features we're working on, what stage they're in, and when we expect to bring them to you. Have any questions or comments about items on the roadmap? Share your feedback via GitHub public feedback discussions.

The roadmap repository is for communicating GitHub’s roadmap. Existing issues are currently read-only, and we are locking conversations, as we get started. Interaction limits are also in place to ensure issues originate from GitHub. We’re planning to iterate on the format of the roadmap itself, and we see potential to engage more in discussions about the future of GitHub products and features. If you have feedback about this roadmap repository itself, such as how the issues are presented, let us know through general feedback in GitHub public feedback discussions.

Guide to the roadmap

Every item on the roadmap is an issue, with a label that indicates each of the following:

• A release phase that describes the next expected phase of the roadmap item. See below for a guide to release phases.

• A feature area that indicates the area of the product to which the item belongs. For a list of current product areas, see below.

• A feature that indicates the feature or product to which the item belongs. For a list of current features, see below.

• One or more product SKU labels that indicate which product SKUs we expect the feature to be available in. For a list of current product SKUs, see below.

• One or more deployment models (cloud, server, and/or ae). Where not stated, features will generally come out Cloud first, and follow on Server and GHAE at or soon after GA.

• Once a feature is delivered, the shipped label will be applied to the roadmap issue and the issue will be closed with a comment linking to the relevant Changelog post.

Release phases

Release phases indicate the stages that the product or feature goes through, from early testing to general availability.

• alpha: Primarily for testing and feedback
  Limited availability, requires pre-release agreement. Features still under heavy development, and subject to change. Not for production use, and no documentation, SLAs or support provided.

• beta: Publicly available in full or limited capacity
  Features mostly complete and documented. Timeline and requirements for GA usually published. No SLAs or support provided.

• ga: Generally available to all customers
  Ready for production use with associated SLA and technical support obligations. Approximately 1-2 quarters from Beta.

Some of our features may still be in the exploratory stages, and have no timeframe available. These are included in the roadmap only for early feedback. These are marked as follows:

• in design:
  Feature in discovery phase. We have decided to build this feature, but are still figuring out how.

• exploring:
  Feature under consideration. We are considering building this feature, and gathering feedback on it.

Release phases - For GHES

Some features may be marked with a GHES 3.X label, which indicates that the feature will also become available for Github Enterprise Server customers. Below are the release version numbers and expected release quarters (Note: these dates are subject to change).

GHES release version dates:

Version Number	Release Quarter	Release Notes
3.5	Q2 2022	Release Notes
3.6	Q3 2022	Release Notes
3.7	Q4 2022	-
3.8	Q1 2023	-

Roadmap stages

The roadmap is arranged on a project board to give a sense for how far out each item is on the horizon. Every product or feature is added to a particular project board column according to the quarter in which it is expected to ship next. Be sure to read the disclaimer below since the roadmap is subject to change, especially further out on the timeline. You'll also find an Exploratory column, which is used in conjunction with the in design and exploring release phase labels for when no timeframe is yet available.

GitHub Enterprise Server has major releases on a quarterly basis, and minor releases on a monthly basis. Once we know what version we are delivering a feature, we will update the issue to indicate that information.

Feature Areas

The following is a list of our current product areas:

• code: Code experiences (Repositories, Pull Requests, Gists)
• planning: Planning and tracking tools (Issues, Projects)
• code-to-cloud: Code-to-cloud DevOps (Actions, Packages)
• collaboration: Collaboration features (Pages, Wikis, Discussions)
• security & compliance: Code security and compliance features
• admin-server: Administrative features specific to GitHub Enterprise Server
• admin-cloud: Administrative features specific to GitHub Cloud
• communities: Community and social features
• ecosystem: Ecosystem and API features
• learning: Education and learning features
• insights: Continuous learning and insights features
• client-apps: Client applications (Desktop, Mobile)
• other: Other features

Feature

The following is a list of our current features and products, with distinct labels for filtering:

• actions: GitHub Actions
• docs: GitHub Docs
• packages: GitHub Packages
• pages: GitHub Pages

More labels will be added in the future as needed.

Product SKUs

The following is a list of our current product SKUs.

• all: Available to all users, including a free tier. Different SKUs may have different levels of functionality.
• github team: GitHub Team
• github enterprise: GitHub Enterprise (Cloud and Server)
• github one: GitHub One (Cloud and Server)
• github ae: GitHub AE (GHAE)
• github advanced security: GitHub Advanced Security (add-on to GHE)
• github insights: GitHub Insights (add-on to GHE)
• github learning lab: GitHub Learning Lab (add-on to GHE)

Disclaimer

Any statement in this repository that is not purely historical is considered a forward-looking statement. Forward-looking statements included in this repository are based on information available to GitHub as of the date they are made, and GitHub assumes no obligation to update any forward-looking statements. The forward-looking product roadmap does not represent a commitment, guarantee, obligation or promise to deliver any product or feature, or to deliver any product and feature by any particular date, and is intended to outline the general development plans. Customers should not rely on this roadmap to make any purchasing decision.

Footnotes

1. We've adopted the latest beta features of GitHub projects for the public roadmap. The roadmap project board within this repository is now closed. ↩

roadmap's Issues

Actions: Reusable workflows work with private repositories

Summary
This feature allows you to create reusable workflows in private repositories.

Intended Outcome
With this feature, you can keep the specifics of your workflow templates private.

How will it work?
Reusable workflows can be shared between private repositories.

Actions: Reusable workflows

Summary
This feature enables you to reuse an entire workflow as if it were an action. Instead of copying and pasting workflow definitions across repositories, you can reference an existing workflow with a single line of configuration.

This issue used to be called “Centrally Managed Workflow Templates.”

Intended Outcome
Use this feature to create a library of reusable workflows. This will DRY your workflow configuration, and make it easier for everyone on your team to get started with Actions. Also see Required Workflows to require these workflows for certain situations, such as deploying to production.

How will it work?
To reuse a workflow, ensure it listens to a new workflow_call event trigger, and then reference it with the familiar uses syntax. Optionally, use inputs and outputs to pass data between them, just like with actions.

For example:

name: Build & Release App

on:
  push:

jobs:
  build:
    uses: example-org/automation/workflows/build.yml@1

  release:
    needs: build
    uses: example-org/automation/workflows/release.yml@1
    with:
      artifact-url: jobs.build.outputs.artifact-url

Reusable workflows which are defined in internal repositories can be used by workflows in any repository within the same Enterprise.

Packages: Support for GHES (Beta)

Summary
GitHub Packages will be available to GHES (GitHub Enterprise Server) for on-premise deployments.

Intended Outcome
GitHub Enterprise Server customers can use GitHub Packages.

How will it work?
This initial release is a beta available to customers for feedback purposes. Features include:

• All existing Packages services:
  • Docker (note: we plan to replace the Docker service with a beta of the GitHub Container Registry in the next GHES release)
  • npm
  • maven/Gradle
  • RubyGems
  • NuGet
• Configurable storage backend (requires AWS S3 or MinIO)
• Private package deletion via APIs and UI

Change the default branch name for new repositories from `master` to `main`

Summary
Many communities, both on GitHub and in the wider Git community, are considering renaming the default branch name of their repository from master. GitHub is gradually renaming the default branch of all our repositories from master to main. We're committed to making the renaming process as seamless as possible for project maintainers and all of their contributors.

Intended Outcome
We’re making changes to GitHub in a few phases, designed to cause as little disruption to existing projects as possible.

• Now: we're supporting early movers by redirecting links that contain a deleted branch name to the corresponding link in the repository's default branch
• This summer: we're introducing a configurable default branch for new repositories
• Later this year: we're enabling seamless branch rename for existing repositories

How will it work?
github/renaming is our up-to-date guidance on how and when to rename your default branch.

Billing API for metered products (i.e. Actions and Packages)

Summary
We are publishing a new /billing REST API endpoint that will provide data on Actions and Packages usage.

Intended Outcome
Customers can integrate with our APIs to monitor their usage.

How will it work?
The first iteration will add endpoints for the current billing cycle: /settings/billing/actions, /settings/billing/packages, /settings/billing/shared-storage.

We will build upon that to allow for expanded time ranges and specified repos/workflows.

Actions: Experience improvements

Summary
Updates to the list of workflows and runs, and checks experience.

Intended Outcome
They make it easier to scan and find specific runs, see an overview of everything that happened in run, and more quickly debug warnings and errors in a workflow.

How will it work?
Browse the list of workflows, runs, and checks to take action more quickly.

Apps: Increased API Limits for GitHub and OAuth apps

Summary
GitHub Enterprise accounts in github.com will receive higher API rate limits for both GitHub and OAuth Apps.

Intended Outcome
API rate limiting is painful when it interrupts the business of shipping software. We want to make sure the API is available to your business and your third party applications at the busiest times.

How will it work?
OAuth Apps will see an increase to 15,000 API calls per hour, from 5,000 API calls per hour. GitHub Apps on organizations with many users and lots of repositories currently have a hard maximum of 12,500 API calls per hour, which will also be raised to 15,000 per hour.

To receive the higher limit, the API call must come from a GitHub App installed on an organization or repository under a GitHub Enterprise subscription. It also applies to an OAuth App authorized to access repositories on organization with a GitHub Enterprise subscription plan, where the user is also part of that organization.

Higher API limits do not apply to OAuth Apps authorized on individual user accounts, and only apply to API requests on organization resources. Higher API limits do not apply to personal access tokens, or PATs. Higher API limits do not apply to unauthenticated requests. Higher API limits do not apply to abuse rate limits or secondary rate limits, which exist to protect GitHub services.

Actions: Additional customization & security for GitHub hosted runners on GHAE (beta)

Summary
GitHub hosted runners will come in new more powerful configurations which can include more CPU cores, RAM, disk space, and specialized hardware like GPUs. You can also use a custom image or optionally enable a static Public IP for use with your firewall. GitHub hosted runners on AE will also deliver the same compliance and security standards as AE. During the beta, customers will not be billed for usage of GitHub hosted runners on GHAE.

Intended Outcome
Our current runners are static in configuration and can be limiting for more intensive or specialized workflows. These new configurations will make running more complicated workflows easier and faster. The additional security capabilities mean customers will not break the GHAE security promise by using GitHub hosted runners.

How will it work?
Specifying the class of runner in your workflow file will determine the power of the runner. More powerful runners will come with higher prices per minute. Additional controls will be available for admins to manage resources and ensure the right organizations and repositories are using the right classes of runners.

Actions: Share self-hosted runners across multiple organizations in an enterprise account

Summary
This feature allows enterprise account owners to manage self-hosted runners that span their entire enterprise, both cloud and server instances.

Intended Outcome
This makes it much easier for enterprises who have many organizations in their account to use their own infrastructure as Runners for their workflows.

How will it work?
Enterprise account owners will register runners with their enterprise account (via the web or API). Once the runners are registered, they will be available for use in the organizations that are in that enterprise.

Actions: Share secrets across multiple repos

Summary
Today, secrets are defined at the repository level. When a team has multiple repositories that all need the same secret, they have to repeat the definition of that secret across all of them. This introduces friction and the possibility of errors. With this feature, users will be able to define secrets for multiple repositories at once.

Intended Outcome
This frees up users to work on more interesting things and reduces the chance of errors. It also enables them to quickly update a secret across multiple repositories, such as in response to a leak.

How will it work?
Users will be able to define a secret at the organization level. They'll be able to specify that all repositories within the organization can access the secret, or a subset of them.

Packages: PHP support

Summary

This is the GA (generally available) release of support for PHP dependency management through Composer.

Intended Outcome

GitHub Packages customers will have the ability to publish public and private PHP packages within their organization. Composer packages published can be shared internally and will benefit from the fine grained access controls connected to GitHub teams available to all other package registry services.

• Language: PHP
• Framework: Composer
• CLI: composer

How will it work?

"repositories": [
    {"type": "composer", "url": "https://php.pkg.github.com/$ORG/"}
],
  "require": {
    "$ORG/package": ">= 1.2.3"
  }

composer install

Codespaces, general availability

Summary
Codespaces provide instant dev environments hosted in the cloud. With Codespaces developers can get going faster with cloud-hosted environments, reducing time-to-first-commit. Enterprises can have the benefit of secure, cloud-hosted environments so code remains cloud-based.

Intended Outcome
Codespaces allows users and organizations to develop in instant cloud environments without acquiring a VDI or rolling their own cloud-hosted development solution.

How will it work?
Developers click "Open in Codespace" from a repo to create a new Codespace which then creates a new environment based on any instructions which may or may not be codified in the repo via a devcontainer to configure the image. If no devcontainer exists, the code is directly added to the kitchen sink, default image. From there developers have a cloud-hosted VS Code environment where they can not only pull in extensions and sync with their local VS Code, but also can run, debug, and live share with other team members.

Secret scanning for private repositories (Cloud)

Summary
This feature extends support for secret scanning to private repositories. For private repositories, GitHub does not automatically send a request to the issuer to revoke the checked-in token. Instead, results are displayed to repo/org admins in the GitHub UI for them to triage.

Intended Outcome
Token leaks are one of the most common security mistakes, and they can have severe consequences. GitHub secret scanning already looks for leaked tokens in public repositories and works with the token-issuer to notify the developer and in some cases automatically revoke the token.

How will it work?
Secret scanning for private repositories will provide more configuration, including the ability to exclude paths and files using config-as-code. In future it will also provide reporting at the organization level.

GitHub Actions for GHES

Summary
With this GA release, GitHub Enterprise Server (GHES) will include Actions.

Intended Outcome
GitHub Enterprise Server customers can use Actions.

How will it work?
Actions on GHES is designed for organizations who want to manage Actions entirely on their own infrastructure (on-premise or cloud). You’ll need to provide the following:

• Compute capacity for the Actions services
• Self-hosted runners
• S3-compatible storage capacity, which will be used for logs, caching, and artifacts

GitHub Actions on GHES includes tools to help you operate the service successfully:

• Key metrics to on the Management Console
• Audit logs
• Access control functionality to rollout Actions in a controlled way

Actions on GHES will be released in two phases:

• Beta
• General availability

Packages: GitHub Packages on GitHub AE (GA)

Summary
GitHub AE will include GitHub Packages.

Intended Outcome
Customers using GHAE can also use Packages.

How will it work?
It should feel just like you're on github.com!

Actions: API

Summary
API to access workflows, jobs, artifacts, logs, secrets, and runners.

Intended Outcome
A few common scenarios are to parse logs for more analysis or automatically add/remove self-hosted runners.

How will it work?
Access through the GitHub APIs.

Dependabot Security Updates (Server Beta)

Summary
Dependabot Security Updates keep projects secure by opening pull requests that update dependencies to a non-vulnerable version.
This extends Dependabot Security Updates to GitHub Enterprise Server (GHES).

Intended Outcome
Update dependencies which have known vulnerabilities. This helps keep a project secure.

How will it work?
Today, Dependabot Security Updates automatically create a pull request in your repository to upgrade a vulnerable dependency to the minimum possible secure version needed to avoid the vulnerability. This is an automated action corresponding to Security Alerts in your repository, for repositories where Dependency Graph is enabled.

Actions: Use actions from internal repositories

Summary
This feature enables workflows to use actions in internal repositories, without having to publish those actions to the GitHub Marketplace.

Intended Outcome
Currently, to use an action in an Actions workflow its code must be in the same repository as the workflow, or a separate public repository, or published to the GitHub Marketplace. This feature allows Actions workflows to use actions that have their code in an internal repository, which is important for customers that need to keep the code of their action private.

How will it work?
Users will be able to mark an internal repository as accessible to any workflow that exists in the same enterprise account.

Actions: Get minutes billed per workflow and per run

Summary
We've made several improvements to help you understand how many minutes are billed for GitHub Actions:

• The Actions API has been enhanced to provide the billed time per workflow and per run.
• Every workflow run now shows both the run time and billed time.
• The billing usage report now specifies the workflow that incurred the hosted runner minutes.

Dependabot version updates: support for private registries (Cloud Beta)

Summary
Dependabot support for private registries allows users to keep private packages secure by opening pull requests to update the packages' dependencies to the latest version.

Intended Outcome
Keep private package dependencies up to date and vulnerability-free.

How will it work?
Today, Dependabot Version Updates updates the packages you rely on to newer versions, even if the version on which you currently rely doesn't have any (known) vulnerabilities. Support for private registries allows users to configure which private registries they are using, and supply credentials for those, to allow Dependabot to update those packages' dependencies.

Security Advisories: CWE and CVSS

Summary
Today, GitHub Security Advisories enable maintainers to privately discuss, fix, and disclose information about vulnerabilities in their projects. This information is used to automatically trigger security updates for participating GitHub repositories. The updated security advisory form will make it easier to provide details required for a CVE.

Intended Outcome

• Maintainers can communicate severity using the CVSS calculator or by providing a CVSS formula from their own calculator
• Maintainers can specify the Common Weakness Enumeration (CWE) that categorizes their vulnerability

How will it work?
During the creation of a Security Advisory, the maintainer will be able to add the CWE and CVSS score.

GitHub Actions for GHES (Beta)

Summary
With this beta release, GitHub Enterprise Server (GHES) will include Actions.

Intended Outcome
GitHub Enterprise Server customers can use Actions.

How will it work?
Actions on GHES is designed for organizations who want to manage Actions entirely on their own infrastructure (on-premise or cloud). You’ll need to provide the following:

• Compute capacity for the Actions services
• Self-hosted runners
• S3-compatible storage capacity, which will be used for logs, caching, and artifacts

GitHub Actions on GHES includes tools to help you operate the service successfully:

• Key metrics to on the Management Console
• Audit logs
• Access control functionality to rollout Actions in a controlled way

Actions on GHES will be released in two phases:

• Beta
• General availability

Org admins in Enterprise accounts can view Actions and Packages usage/billing

Summary
Currently, organization admins for orgs that belong to Enterprises cannot view their usage of Actions and Packages as it relates to billing. This lack of visibility makes it difficult to manage usage and understand when it may be necessary to enable overages for the Enterprise as a whole.

Intended Outcome
Organization admins will have better visibility into their usage which will help them manage usage and understand when it may be necessary to enable overages for the Enterprise as a whole.

How will it work?
The organization level billing page will show the usage for the organization and an aggregation of the sister orgs that belong to the same Enterprise account. Organization admins will be able to understand the usage of their organization and the all-up Enterprise.

Visit our Actions and Packages documentation to learn more.

Actions: Policies for using external actions

Summary
This feature enables enterprise, organization, and repository admins to limit external actions in their workflows to an "allow list" they control.

Intended Outcome
Admins can choose which external actions are available to their developers to utilize.

How will it work?
Admins can create an 'allow list' of external actions. Only actions on the list will be available to their developers. Any workflows that reference an external action outside of the list will fail.

Pages: Private Access

Summary
For GitHub Enterprise users, they'll be able to make their Pages sites private to the world. Only those individuals that have access to the repository housing the site will have access to the private pages site.

Intended Outcome
In cases where organizations want to build an intranet site or publish internal documentation, private pages will allow organization to keep the content private to their organizations.

How will it work?
For Enterprise Cloud customers, if a repository is private, they'll be able to go to the Pages settings and change the visibility of the pages site from public to private. Once that change is made, a new pages URL will be created that's distinct from the rest of the pages sites that exists within that organization.

Code scanning (Server)

Summary
We're integrating CodeQL analysis into GitHub, and building an interface for displaying static analysis results more generally. GitHub will show analysis results in the repository and pull request experiences.

Intended Outcome
We want high-quality, automated security review to be a native and positive part of the developer workflow. Integrating static analysis results directly into the PR experience will help engineering teams catch security vulnerabilities earlier.

How will it work?
Advanced Security users will be able to set up a CI workflow (e.g., using GitHub Actions or Jenkins) that runs CodeQL analysis on each pull request, or on a schedule, and posts the results to GitHub using a standard static analysis result format (SARIF). GitHub will determine which alerts are new as a result of the code changed in the pull request and surface any potential vulnerabilities in-line.

Actions: Pull requests from private forks run Actions workflows

Summary
Today, Actions workflows only run for pull requests where the source is a branch in the same repository or a public fork.

Intended Outcome
After this is complete, all pull requests sources can run Actions workflows.

How will it work?
This will enable pull requests from private forks to run workflows, which is a common workflow.

Actions: Required workflows

Summary

Required workflows allow DevOps teams / CICD system administrators to define mandated workflows to run during the lifecycle of a repository’s pipeline. Individual development teams at the repository level will be able to see what required workflows have been applied to their repository, what actions that workflow performs, and whom to contact if they have questions.

In addition to reducing duplication of CI/CD configuration code, required workflows can also help companies with the following use cases:

• Security: Invoke external vulnerability scoring or dynamic analysis tools beyond CodeQL or Dependabot.
• Correctness and Compliance: Ensure that all code meets an enterprise’s quality standards. e.g., Enforce consistent code syntax conventions, or ensure that unit test coverage meets a minimum level before deployments are permitted.
• Deployment: Ensure that code is continuously deployed in a standard way.

Intended Outcome

Required workflows allows DevOps teams to define and enforce standard CI/CD practices across many source code repositories within an organization without needing to configure each repository individually, which becomes an impossible task in large organizations.

How will it work?

Workflow documents can be selected by an administrator from any repository in an organization (the "source" repo or "imposer" repo) and applied to one or more target repositories (the "imposee"). The first version of required workflows will support workflows using the pull_request webhook only.

Code scanning (Cloud)

Summary
We're integrating CodeQL analysis into GitHub, and building an interface for displaying static analysis results more generally. GitHub will show analysis results in the repository and pull request experiences.

Intended Outcome
We want high-quality, automated security review to be a native and positive part of the developer workflow. Integrating static analysis results directly into the PR experience will help engineering teams catch security vulnerabilities earlier.

How will it work?
Advanced Security users will be able to set up an Actions workflow that runs CodeQL analysis on each pull request, or on a schedule, and posts the results to GitHub using a standard static analysis result format (SARIF). GitHub will determine which alerts are new as a result of the code changed in the pull request and surface any potential vulnerabilities in-line.

Actions: Manual trigger in workflows

Summary
Allow users to manually trigger workflows that either do not run on any other event or may run on push and also need to be manually triggered.

Intended Outcome
Address customer feedback around manually running a workflow.

How will it work?
Workflow authors will be able to specify a new manual event in the on section of their workflow. As part of that event they will be able to specify a set of inputs they would like to request from the user as well as if the workflow can be manually triggered on any branch of only protected branches. Workflows that specify the manual event will have a new button that will provide a branch picker and list out the inputs that have been defined. When the workflow is run the values provided by the user will be present in the new manual event payload and can be accessed using the ${{ github.event.inputs.<input_name> }} expression.

Actions: GitHub Actions on GitHub AE (Beta)

Summary

A beta of GitHub Actions is available to GitHub AE.

Intended Outcome

Customers can test out, and provide feedback on, GitHub Actions for their instances.

How will it work?

Customers can choose whether they'd like to participate. More information will be provided at a later point.

Packages: Python (PyPi) support

Summary

This is the GA (generally available) release of support for Python packages PyPi supporting the pip client.

Intended Outcome

GitHub Packages users will have access to a public and private PyPI package management server for distributing Python packages both publicly and privately within their organization.

• Language: Python
• Framework: PyPI
• CLI: pip

How will it work?

Set GitHub Packages as a repository

[packages]
repository: https://pypi.pkg.github.com/$USER_OR_ORG/
username: $GITHUB_PERSONAL_ACCESS_TOKEN
password:

Use the Packages repository for pushing

python setup.py sdist upload -r packages

Actions: Self-hosted runner groups

Summary
Self-hosted runner groups allow enterprise and organization admins to assign a subset of their self-hosted runners to specific organizations or repositories. This feature is only available in the GitHub Enterprise SKU.

Intended Outcome
This will make it easier for admins to limit access to groups of runners to the right organizations and repositories. For example, perhaps only a single organization in your enterprise account should be accessing VMs with GPUs. Another common scenario is to have a set of self-hosted runners dedicated to production deployment and only give access to the repositories that need them.

How will it work?
Enterprise account admins can go to Policies -> Actions -> Runners. They can then create groups and assign runners to them. The group can have one of 4 visibility levels: all repositories, private repositories, or selected repositories. Organization admins will find these same controls under Org Settings -> Actions.

Dependency Graph: Dependency Review (Cloud)

Summary
Review Dependency Changes allows a reviewer to see dependencies and vulnerabilities in those dependencies they are introducing as part of PRs.

Intended Outcome
Have information in a pull request to know if you are introducing any new dependencies or vulnerabilities before these are added to your environment.

How will it work?
Today, Dependency Graph helps you understand your dependencies, and Security alerts notify you of newly discovered vulnerabilities in your dependencies. In a PR merging a branch to master, you will be able to get predictive information from the Dependency Graph and Security alerts before merging a branch, to see if you are introducing new dependencies or vulnerabilities before these are added to your environment.

Packages: GitHub Packages on GitHub AE (Beta)

Summary
GitHub AE will include GitHub Packages.

Intended Outcome
Customers using GHAE can also use Packages.

How will it work?
It should feel just like you're on github.com!

Packages: Support for GHES

Summary
GitHub Packages will be available to GHES (GitHub Enterprise Server) for on-premise deployments.

Intended Outcome
GitHub Enterprise Server customers can use GitHub Packages.

How will it work?
This is the GA (General Availability) release to customers. Features include:

• The following Packages services:
  • npm
  • maven
  • RubyGems
  • NuGet
• Configurable storage backend (requires AWS S3, MinIO, or Azure blob storage)
• Admin controls for enabling/disabling specific package types and per organization
• Private package deletion via APIs and UI

Actions: Delete workflow runs

Summary
Today users are not able to remove workflow runs from the list in actions. This can lead to a very cluttered view with lots of items that are not longer interesting or to security issues if secrets are accidentally leaked into a log.

Intended Outcome
Users can delete workflow runs that are no longer useful which will remove their logs and free up storage in their repository.

How will it work?
There will be a new menu option for the run and workflow commands that will allow you to delete the workflow run.

Secret scanning (Server Beta)

Summary
This feature extends support for secret scanning to private and public repositories on server. For server, GitHub does not automatically send a request to the issuer to revoke the checked-in token. Instead, results are displayed to repo/org admins in the GitHub UI for them to triage.

Intended Outcome
Token leaks are one of the most common security mistakes, and they can have severe consequences. GitHub secret scanning already looks for leaked tokens in public repositories and works with the token-issuer to notify the developer and in some cases automatically revoke the token.

How will it work?
Secret scanning for Server will provide more configuration, including the ability to exclude paths and files using config-as-code. In future it will also provide reporting at the organization level.

Actions: GitHub Enterprise Server can use GitHub-managed runners with GitHub Connect

Summary
This feature enables GHES to use Actions hosted runners for their workflows.

Intended Outcome
Currently, GitHub Enterprise Server (GHES) can only use self-hosted runners with Actions. This will make it easier for GHES customers to run their workflows with hosted runners that require no configuration.

How will it work?
Actions hosted runners provide VMs for Windows, Linux, and Mac with the common tools needed to build, test, and deploy your code. They automatically scale with a simple pay-as-you-go model so there is no maintenance.

Actions: Workflow visualization

Summary

This feature will allow users provides a real-time, visual graph of their workflow as it runs so users can see how it’s progressing.

Intended outcome

This makes it easier for users to assess progress of their workflows as they run, and to more easily identify problems for troubleshooting. This will save time and make it easier to communicate status to others, especially for complicated or lengthy workflows.

How will it work

For each workflow, a visual graph will be generated, with color coding to identify success, in progress, or failure of a particular step. Each step will include metadata and deep-linking to help speed investigations of any underlying workflow or source code files that may be needed.

Enterprise explore page and improved InnerSource discovery

Summary
Companies want the same tools we build for open source collaboration to also work for teams across an organization. They want to unlock increased cross-company collaboration and code reuse using InnerSource facilities that help teams discover and engage with one another.

Last year we introduced enterprise accounts and internal repository visibility, setting a great foundation. This year we are taking a bolder step forward by enabling a new enterprise wide explore experience that showcases technology and software development within the company while providing InnerSource discovery and community interaction.

Intended Outcome
Enable an InnerSource culture within enterprises.

How will it work?
Users who are members of enterprise accounts will be able to navigate to the enterprise explore home page and:

• Explore a curated feed of trending projects and communities
• Search for InnerSource code
• See all organizations belonging to the enterprise

Actions: Increase the cache size for a repo using shared storage

Summary
GitHub Actions enables customers to cache intermediate outputs and dependencies for their workflows via the cache action. Currently this storage is limited to 5GB pre repository and is rotated based on the last access time for a given cache entry.

Intended Outcome
Having the ability to expand the cache size for a given repo can enable customers to improve the performance of their workflows for more scenarios and larger repos.

How will it work?
We are now doubling the cache storage limit to 10 GB/repository to enable more customers to experience faster Jobs using GitHub actions.

Dependency Graph: Dependency Review (Cloud Beta)

Summary
Review Dependency Changes allows a reviewer to see dependencies and vulnerabilities in those dependencies they are introducing as part of PRs.

Intended Outcome
Have information in a pull request to know if you are introducing any new dependencies or vulnerabilities before these are added to your environment.

How will it work?
Today, Dependency Graph helps you understand your dependencies, and Security alerts notify you of newly discovered vulnerabilities in your dependencies. In a PR merging a branch to master, you will be able to get predictive information from the Dependency Graph and Security alerts before merging a branch, to see if you are introducing new dependencies or vulnerabilities before these are added to your environment.

Actions: Share self-hosted runners across multiple repos

Summary
Actions self-hosted runners can be made available to the entire organization or just part of it.

Intended Outcome
This makes it easier to share a single set of runners across multiple repositories.

How will it work?
Custom Runner labels enable you to route your workflows to the specific Runners you need. For example, if you have a set of large VMs or GPU VMs that you need for a specific set of workflows, you can make sure workflows that need them only run on those VMs.

Actions: Manual approvals in workflows (Beta)

Summary
Deploying to production environments often requires a person to approve it, to meet certain security and compliance policies. Manual approvals enable you to control when workflows are allowed to deploy to specific environments by requiring a specific person or team to approve a workflow run before it can proceed.

Intended Outcome
This allows time for manual inspection and verification of the artifacts being deployed.

How will it work?
Finally, organizations will be able to configure rules about approvals such as not allowing the actor that triggered the run to be the same actor that approves it. Or use the API to integrate with existing change control systems.

Dependabot Security Updates (Server)

Summary
Dependabot Security Updates keep projects secure by opening pull requests that update dependencies to a non-vulnerable version.
This extends Dependabot Security Updates to GitHub Enterprise Server (GHES).

Intended Outcome
Update dependencies which have known vulnerabilities. This helps keep a project secure.

How will it work?
Today, Dependabot Security Updates automatically create a pull request in your repository to upgrade a vulnerable dependency to the minimum possible secure version needed to avoid the vulnerability. This is an automated action corresponding to Security Alerts in your repository, for repositories where Dependency Graph is enabled.

Dependabot Version Updates (Cloud)

Summary
Dependabot Version Updates keep projects secure by opening pull requests that update dependencies to the latest version.

Intended Outcome
Keep project dependencies up to date. This helps keep a project secure as patches may only be available on the latest version(s) of a dependency, or security patches may be released without being (initially) announced. This also ensures that projects can be regularly updated, so that a critical patch will require a 'smaller' upgrade.

How will it work?
Today, Dependabot Security Updates can help you avoid vulnerabilities in packages you rely on by automatically updating you to a non-vulnerable version - this functionality similarly regularly updates the packages you rely on to newer versions, even if the version on which you currently rely doesn't have any (known) vulnerabilities.
This includes GA for Dependabot support for private registries.

Actions: Create and share workflows templates in an organization

Summary
Today, when developers use the GitHub interface to create a new workflow they see a number of "starter workflows" to choose from:

These workflows are available to all repositories and are defined in the actions/starter-workflows repository.

Intended Outcome
With this feature, users will be able to define their own starter workflows. These will be defined at the organization level, and will be made available to every repository within the organization.

How will it work?
When developers create a new workflow, they will see these custom workflows and can choose whether to use them or not.

Create a custom list of emails to receive billing threshold notifications

Summary
Account and billing admins can provide a list of emails to receive billing threshold notifications (e.g. you've used 75% of included Actions minutes). Additionally, the billing email will also receive the threshold notifications.

Intended Outcome
Account and billing admins can decide who gets notified when the account has passed usage thresholds. The email provided could be for a user in the account who isn't an admin; it could be a distribution list, or even someone who is not a paid seat in your GitHub instance (e.g. in the procurement department at your company).

How will it work?
Account and billing admins provide a list of emails to receive usage notifications outside of the typical audience of account and billing admins. We will send emails to the specified recipients when the account has passed the various billing thresholds for metered products like Actions and Packages.

Visit the documentation on how to set a billing email to learn more.

Actions: GitHub Enterprise Server can support Google Cloud Storage

Summary
Adds support for Google Cloud Storage as a blob storage provider for Actions on GitHub Enterprise Server.

Intended Outcome
GitHub Actions for Enterprise Server requires an S3-compatible blob storage provider. Before this release, supported options are: S3, Azure Blob Storage, and Min.io with NAS Gateway.

This release adds support for Google Cloud Storage, enabling customers to run GitHub Enterprise Server entirely in Google Cloud Platform.

How will it work?
Administrators will use the Enterprise Server management console or CLI to configure Actions to use Google Cloud Storage.