enterprise

Subscribe to all “enterprise” posts via RSS or follow GitHub Changelog on Twitter to stay updated on everything we ship.

~ cd github-changelog
~/github-changelog|main git log main
showing all changes successfully

On July 31 we announced that network requests for Copilot would be routed based on a user’s Copilot subscription, giving customers the ability to block access to Copilot Individual. This change enables Copilot Business and Copilot Enterprise customers to make sure all Copilot users on their networks are accessing Copilot through their Copilot Business or Copilot Enterprise subscription, and that all Copilot user data is handled according to the terms of their Copilot Business or Copilot Enterprise agreement.

We have rolled back that release in order to allow customers more time to make any necessary adjustments to their firewall settings.

On November 4, we will enable the feature and ensure that users are accessing Copilot through the specific endpoints for their Copilot subscriptions. This means only Copilot Business users will be able to connect to Copilot Business endpoints and only Copilot Enterprise users will be able to connect to Copilot Enterprise endpoints.

Important next steps to ensure continued access to Copilot

Between now and November 4, all Copilot customers should ensure they are following the firewall settings published in our docs. Specifically, this means customers should ensure access is allowed to the wildcard hostname https://*.githubcopilot.com, along with the other listed hostnames.

In order to ensure continued access to Copilot after November 4, all Copilot customers should:

  • Ensure access is allowed to the subscription-specific hostnames https://*.business.githubcopilot.com (for Copilot Business) or https://*.enterprise.githubcopilot.com (for Copilot Enterprise)
  • Update their IDE clients to at least these minimum versions:
  • For Visual Studio Code, use Copilot Chat version 0.17 or later
  • For JetBrains IDEs, use Copilot version 1.5.6.5692 or later
  • For Visual Studio, use version VS 2022 17.11 or later

Customers with an account rep that want to block access to Copilot Individual on their network before November 4 should follow these instructions instead of the previously published firewall docs:

  • Ask their account rep to opt them into the feature without waiting
  • Block access to https://*.individual.githubcopilot.com
  • Ensure access is allowed to the subscription-specific hostnames https://*.business.githubcopilot.com (for Copilot Business) or https://*.enterprise.githubcopilot.com (for Copilot Enterprise)
  • Update their IDE clients to at least these minimum versions:
  • For Visual Studio Code, use Copilot Chat version 0.17 or later
  • For JetBrains IDEs, use Copilot version 1.5.6.5692 or later
  • For Visual Studio, use version VS 2022 17.11 or later

Read more about subscription-based network routing here.

See more

Enterprise managed users (EMUs) must now prove ownership of their email addresses. Existing EMU account email addresses do not have to take this step unless the email address matches one on another GitHub.com account.

Enterprises with EMU accounts that have conflicts have received notification from GitHub regarding specific accounts that have an email address which also exists on another github.com account. Certain 3rd party applications may not work correctly until they have reverified their email address.

New EMU accounts will have their enterprise’s shortcode appended to their email address’s prefix until it is verified, or their administrator changes the email address to another value.

To verify an email address, follow the steps outlined in our documentation. EMU account email addresses are defined by your identity provider, and cannot be changed directly within GitHub. You will need to work with your IdP administrator to change your email address if necessary.

Some users may find that 3rd party GitHub Apps and OAuth apps may not handle the placeholder email correctly, resulting in missing data in these apps. In rare cases, Enterprise Owners may also find that their email provider does not support the “plus addressing” scheme in use. Developers can review our best practices for OAuth and GitHub App implementation, including the use of the id field when storing user reference data so that email address changes are not disruptive to a user’s apps experience.

See more

Today, we are expanding our “pay-as-you-go” model to include GitHub Enterprise (GHE) and GitHub Advanced Security (GHAS) — unifying the GitHub product portfolio as metered services. This provides our customers a frictionless procurement & billing experience, adds flexibility with self-provisioning & pay-as-you-go pricing, and expands pathways to purchase GitHub products through Microsoft.

Enterprise accounts on GitHub.com, created on or after August 1, 2024, will support a consumption-based metered billing model for both GHE and GHAS — enabling you to pay for the licenses you consume in a given month at month’s end as opposed to pre-purchasing for the month ahead.

Further, as part of this release, pay-as-you-go enterprises will enjoy:

  • Access to our new, enhanced billing platform
  • Expanded self-provisioning experiences for GHE and GHAS – including the option to set up an Enterprise Managed Users (EMUs) configuration
  • The ability to add your Azure subscription as a new payment method across your entire account
  • Eligibility for Microsoft Azure Consumption Commitments (MACC) and Azure Commitment Discounts (ACD) when connected to an Azure subscription

For existing customers with GitHub Enterprise (GHE) already, your plan and existing billing method will remain as is. If you have an account team, please connect with them to discuss whether this new billing method is an option for you. For customers without an account team, an in-product prompt will be shown once your account is eligible for this option. If you are upgrading from a Free or Team plan through a GitHub Enterprise trial, your new enterprise will immediately support consumption-based metered billing for GHE and GHAS.

Learn more about this change by reading our article on our new metered billing offerings.

See more

Note: This feature has been rolled back. For the latest information about this capability, view this new post

Starting today, network requests for Copilot are routed based on a user’s Copilot subscription. Requests for Copilot Individual, Copilot Business, and Copilot Enterprise users now route through different endpoints.

This change enables Copilot Business and Copilot Enterprise customers to make sure all Copilot users on their networks are accessing Copilot through their Copilot Business or Copilot Enterprise subscription, and that all Copilot user data is handled according to the terms of their Copilot Business or Copilot Enterprise agreement. In essence, customers will be able to use their network firewall to explicitly allow access to Copilot Business or Copilot Enterprise, and/or block access to Copilot Individual.

In 90 days, on October 31, 2024 we will enable enforcement of the user’s subscription on the new endpoints, ensuring only Copilot Business users can connect to Copilot Business endpoints and only Copilot Enterprise users can connect to Copilot Enterprise endpoints.

Read more about subscription-based network routing here.

See more

Copilot Chat and pull request summary generation now use GPT-4o, bringing the performance of OpenAI’s latest flagship model to all developers.

Copilot Chat is available in Visual Studio, VS Code, JetBrains IDEs, GitHub Mobile apps, and GitHub.com.

To use the new GPT-4o model in your IDE, ensure you are using at least the minimum version of Copilot Chat specified here:

What this means for Copilot users

With this upgrade to GPT-4o, Copilot users will experience the following benefits:

  1. Faster response times – up to 55% faster TTFT (time to first byte)
  2. More accurate and reliable Copilot Chat responses – our testing showed a 60% increase in user satisfaction.

Commitment to quality

The upgrade process focused on our unwavering commitment to quality, safety, and security. Here’s what that entailed:

  1. Offline and online evaluation: We performed rigorous offline and online testing to ensure the model brings tangible benefits to users. This involved thorough benchmarking and running simulations of real-world software development scenarios to validate the improved performance and accuracy of GPT-4o.
  2. Red teaming: To preemptively address any potential safety issues, we conducted extensive red teaming exercises. These tests challenged the model to ensure it meets our high standards for safety and reliability in diverse coding environments.

We can’t wait to see what you create with the new GPT-4o-powered Copilot!

Let us know your feedback and join the discussion within the GitHub Community.

Happy coding!

See more

Actions Usage Metrics is now generally available for all GitHub Enterprise Cloud customers. Actions Usage Metrics enables you to view data about your Actions workflow runs throughout your organization. You can use this data to identify opportunities to optimize your pipelines and reduce wasted runtime minutes which, when addressed, can lead to faster runs and increased developer productivity. Actions Usage Metrics breaks down the utilization of workflows, jobs, source repositories, and operating systems for GitHub hosted runners and self-hosted runners. All of this data is available in the UI and can be exported and shared as a .csv file if you wish to integrate your usage data with internal or third party tools.

Actions Usage Metrics screen shot!

To learn more about Actions Usage Metrics, check out our docs or head to our community discussion to ask questions and provide feedback.

See more

Enterprise Owners on GitHub Enterprise Cloud (GHEC) can join a private beta allowing them to configure audit log streaming via the REST API. This private beta grants access to new API endpoints for the following audit log streaming actions:

  • GET Endpoint Configuration: Retrieve the audit log streaming configuration for your Enterprise.
  • Stream Key Endpoint: Provide the customer with an audit streaming key. This key is essential for our customers to encrypt their secrets before sending them via an API call.
  • POST Endpoint: Create new audit log stream configurations.
  • PUT Endpoint: Update existing audit log stream configurations.
  • DELETE Endpoint: Delete existing audit log stream configurations.

With the introduction of these new REST API endpoints, enterprise owners can programmatically create, update, delete and list their Enterprise’s audit log streams. By allowing programmatic updates to the audit log streaming configuration, customers can automate tasks like rotating your audit log streaming secrets.

These new audit log streaming endpoints will impose a rate limit of 15 API requests per hour to protect the availability of the audit log streaming service. For the time being, these endpoints are only accessible via personal access token (PAT) classic and OAuth token with admin:enterprise scope.

Enterprise owners interested in participating in the private beta should reach out to your GitHub account manager or contact our sales team to have this feature enabled for your enterprise. Enterprise owners can follow instructions for these API endpoints, and provide feedback on their experience on our community discussion.

See more

Organization owners can now grant a user or team access to all of the repositories in their org with a single click. Five new pre-defined roles have been added to the organization settings, under Organization Roles > Role Management, where all organization owners can view and assign them.

Pre-defined roles ship natively with GitHub. We will add more pre-defined roles over time that support common personas like “CI/CD Admin” or “Security Manager”.

A screenshot showing the five new roles in the organization settings

Introducing pre-defined roles and organization-wide repository permissioning

These five new roles showcase an expansion of organization roles – the ability to also include repository-level base roles (like read) and permissions (like close issue). When granted, the recipient has those privileges on all of the repositories in the organization, current and future. While organization owners cannot yet create organization roles that include repository permissions, that will be supported in the coming months.

A screenshot of the Triage role expanded to show the repository permissions included in the role

This new functionality of organization roles helps organizations replace automation that watches for new repository creation and adds the right users or team to every repository.

UI updates to show role assignments

When users and teams are assigned access across all repositories, this is called out in the team and repository view rather than list all of the accesses.

A screenshot showing that this team has access to all of the repositories in the organization. Below it is a listing of the repositories that the team has been given specific access to.

In addition, the Roles Management view in the organization settings has been updated to show indirect assignments – these are roles that a user or team recieves due to a team that they are a member of. This provides a full accounting of all organization roles that a user or team has within the organization.

A screenshot showing a user that has been granted two roles. One is directly assigned, and has a remove button on the right hand side of the row. The other is indirectly assigned via a team named org-member-parent-team, and does not have a remove option.

The APIs for organization role management have been updated to support these pre-defined roles. You’ll find a base_role field in the description of the organization role, which is the repository role (like read) that is included in the organization role.

You can learn more about organization roles at “Using organization roles“.

See more

We revamped the Enterprise Cloud Licensing page content.

ghe-subscription-example

  • Enhanced Usability: We’ve simplified how license usage is presented for enterprises using the Visual Studio Subscription with GitHub Enterprise license bundle, making it clearer and easier to understand your usage metrics.
  • Optimized CSV Download Experience: We updated the Licensing page’s CSV download feature to provide better feedback on the report’s status. For reports with a large volume of data, we now email the CSV report to you once it’s ready.

Join the discussion within GitHub Community.

See more

GitHub is committed to a secure software ecosystem and requires most developers who contribute code on GitHub.com to enable one or more forms of two-factor authentication (2FA).To ensure that all users stay up to date with their account security configurations, we are now improving the checkup experience using various global banners that guide users to review and update their settings on a more regular basis.

These banners replace the security checkup interstitials that were previously displayed every 3 months for 2FA users. Each banner calls out the specific security configuration that needs attention (ex: user only having a single verified email), and will also include a quick link to the corresponding settings page to modify the required settings.

To learn more about the 2FA program, see our April 2024 blog post about how GitHub is securing millions of developers using 2FA, as well as the “About the mandatory 2FA program” documentation.

See more

Starting September 3, 2024 enterprise customers who currently have a single organization without an enterprise account will be automatically upgraded into an enterprise account at no additional cost. An enterprise account will be created for you, and your organization will become the first member organization.

In April 2023, we introduced enterprise accounts for all new enterprise customers. We outlined our plans to assist existing customers with a single organization in obtaining an enterprise account. Enterprise accounts provide a unified experience granting access to all the latest and most robust features within the platform.

What is an enterprise account?

Enterprise accounts represent the top-most layer of the GitHub Enterprise management hierarchy, allowing enterprise owners to manage and scale their GitHub environments. Essentially, the enterprise account sits above organizations and serves as the primary interface for enterprise owners.

Benefits of an enterprise account:

Timeline & Next Steps:

If you have a GitHub Enterprise Cloud account without an enterprise account:

  • Voluntary Upgrade (Now – September 3rd, 2024): Administrators can proactively upgrade their existing account to an enterprise account via the Billing and Plans page under the account’s settings.
  • Automatic Upgrade (Starting September 3rd, 2024): If an upgrade was not completed during the voluntary phase, the account will be assigned a scheduled upgrade date. We’ll notify administrators two weeks prior to this date.
  • Seamless Transition: On the scheduled upgrade date, if not yet upgraded, the account will seamlessly transition and be nested under a new assigned enterprise account.

  • The new enterprise account name will match the organization name or as close as possible if the name is already taken, and customers may choose to rename after the upgrade.

  • There will be no change in ownership, all of the existing owners will remain the owners of the new enterprise account. The organization’s URL will not change, so existing usage of the repos or organization URL will not be impacted.
  • The existing configuration such as SAML SSO, PATs, policies, and application integrations should remain with the organization, unless there’s an override at the enterprise account.
See more

The GitHub Enterprise Server 3.13 release is generally available

GitHub Enterprise Server 3.13 gives customers more fine-grained control over deployment requirements and enhanced security controls. Here are a few highlights:

  • We are introducing a new feature for repositories called custom properties, a major enhancement to how repositories are managed and classified across GitHub organizations. Properties offer a flexible way to add meaningful metadata to your repositories that simplifies repository classification, enhances discoverability, and seamlessly integrates with rulesets. Check out the demo! For more information, see custom properties for repositories.
  • Elasticsearch will be upgraded from version 5 to version 8, when the appliance is upgraded to 3.13. Elasticsearch powers all search experiences in GHES including code search and audit logs. Upgrading ES5 to ES8 allows the platform to take advantage of better performance and improved security posture in ES8. For more information regarding what to expect during ES8 upgrade, see Preparing for Elasticsearch upgrade in GHES 3.13.
  • Enterprise and organization audit log events now include the applicable SAML and SCIM identity data associated with the user. For more information, see Reviewing the audit log for your organization.
  • Developers who use devcontainer.json files to define their development containers will now be able to use Dependabot version updates to keep their dependencies in the container up-to-date. Once configured in dependabot.yml, Dependabot will open PRs on a specified schedule to update the listed dependencies to latest.
  • Pull Requests rebases are now faster! Under the hood, rebase commits now use the merge-ort. Rebases that timed out for large repositories before are now a lot more likely to be successful.
  • Using Project Status Updates, you can now provide high level details on the status, timing, and progress of your project, directly from the project! This makes it easy to know and share with others how your work is progressing, any risks, and a history of when and why something changed, all in the same place where you’re tracking your work.

Read more about GitHub Enterprise Server 3.13 in the release notes,
or download it now.

If you have any issues upgrading your GitHub Enterprise Server Appliance to version 3.13, or problems using new features, please contact our Support team.

Please join us on GitHub Community to share your feedback or ask any questions about the new features!

See more

The GitHub Enterprise Server 3.13 release candidate is here

GitHub Enterprise Server 3.13 gives customers more fine-grained control over deployment requirements, and enhanced security controls. Here are a few highlights:

  • We are introducing a new feature for repositories called custom properties, a major enhancement to how repositories are managed and classified across GitHub organizations. Properties offer a flexible way to add meaningful metadata to your repositories that simplifies repository classification, enhances discoverability, and seamlessly integrates with rulesets. Check out the demo! For more information, see custom properties for repositories.
  • Elasticsearch will be upgraded from version 5 to version 8, when the appliance is upgraded to 3.13. Elasticsearch powers all search experiences in GHES including code search and audit logs. Upgrading ES5 to ES8 allows the platform to take advantage of better performance and improved security posture in ES8. For more information regarding what to expect during ES8 upgrade, see Preparing for Elasticsearch upgrade in GHES 3.13. Downnload the 3.13 RC candidate now, upgrade your staging environment and share your feedback with us!

  • Enterprise and organization audit log events now include the applicable SAML and SCIM identity data associated with the user. For more information, see Reviewing the audit log for your organization.

  • Developers who use devcontainer.json files to define their development containers will now be able to use Dependabot version updates to keep their dependencies in the container up-to-date. Once configured in dependabot.yml, Dependabot will open PRs on a specified schedule to update the listed dependencies to latest.

  • Pull Requests rebases are now faster! Under the hood, rebase commits now use the merge-ort. Rebases that timed out for large repositories before are now a lot more likely to be successful.

  • Using Project Status Updates, you can now provide high level details on the status, timing, and progress of your project, directly from the project! This makes it easy to know and share with others how your work is progressing, any risks, and a history of when and why something changed, all in the same place where you’re tracking your work.

Release Candidates are a way for you to try the latest features early, and they help us gather feedback to
ensure the release works in your environment. They should be tested on non-production environments.
Read more about the release candidate process.

Read more about GitHub Enterprise Server 3.13 in the release notes,
or download the release candidate now.
If you have any feedback or questions, please contact our Support team.

See more

The enterprise support portal at https://enterprise.githubsupport.com/ has been deprecated since November 1, 2021. However, it has continued to remain accessible to view past tickets. That is now changing. In order to streamline your support experience, we are going to turn the portal off and it will no longer be accessible after May 31st, 2024.

Action required: If you have used this portal to reference old tickets not available on support.github.com, we recommend that you copy any important information from those tickets to another location before the end of this month.

You must visit support.github.com with a support entitled account to open new support tickets about your GitHub enterprise cloud account.

See more