GitHub Upgrade – 3.9.1

On Monday, July 24th, the GitHub Service Team will be taking the NC State GitHub Enterprise service offline for an upgrade to version 3.9.1 which includes all changes from 3.9.0.

During the outage no one will be able to login or interact with the service in any way. We do not expect the upgrade to take more than the scheduled period. In the event that more time is needed, we will update this status.

This changelog is not exhaustive. To view a complete list of changes in this upgrade, please see the GitHub Enterprise 3.9.1 release notes.

Security fixes

• Packages have been updated to the latest security versions.

Bug fixes

• In some cases, users could reopen a pull request that should not have been able to be reopened.
• .topojson files would not render correctly, but files that conformed to the TopoJSON spec that used a .geojson extension would render correctly.
• In some cases, pull requests with more than 25 rich-diff renderable files required that users toggle the diff type to correctly render the files over the 25-file limit.
• In rare circumstances, Git commits signed with SSH keys using the RSA algorithm would incorrectly indicate the signature was invalid.
• On an instance with many organizations, the enterprise security overview page returned a 500 error.
• Users were unable to configure a SSH certificate authority for an organization.
• Events related to repository notifications did not appear in the audit log.
• On an instance with GitHub Actions enabled, links to http(s)://HOSTNAME/features/actions from the web UI returned a 500 error.
• If a user added a new item to a projects roadmap view, and the item was outside of the viewport, the view would crash and display “This project failed to load”.
• The audit log reported the incorrect target repository for pre-receive hook failures.
• Users can add issues and pull requests from any organization to a project, and are no longer limited to the user or organization of the project.
• On an instance with GitHub Actions enabled and a GitHub Advanced Security license, enterprise-level runner scale sets with the code-scanning label were not sufficient to allow default setup for code scanning.

Changes

• To provide additional context within the web interface on an instance where Dependabot alerts are enabled, links to Dependabot alerts in an issue or pull request comment display an improved label and hovercard with alert details.
• On an instance with Dependabot alerts enabled, people with write or maintain access to a repository can view or act on Dependabot alerts by default. Custom roles, the security manager role, organization permissions, and notification settings are not affected.
• In the security overview’s “Security risk” and “Security coverage” views, when a user selects a team from the “Team” drop-down or filters by team, results appear for repositories where the team has write or administrative access or has been granted access to security alerts. Previously, users could only view results for repositories where the team had administrative access or had been granted access to security alerts.
• To provide more context within a project, users can share a deep link to a specific issue in a project to have the issue open in the project’s side panel.
• Organization owners can create up to five custom repository roles. Previously, the limit was three. For more information, see “About custom repository roles.”
• When transferring a repository, users can also rename the repository. For more information, see “Transferring a repository.”
• If a user archives a repository, responses from the GraphQL API that include information about the repository now include an archivedAt value with a timestamp representing the archival date.

Features

• REST API
  • To provide API integrators a smooth migration path and time to update integrations after GitHub makes occasional breaking changes, the REST API now uses calendar-based versioning. GitHub Enterprise Server 3.9 provides version 2022-11-28 of the REST API. For more information, see “API Versions” in the REST API documentation

• Dependabot
  • To improve the security of GitHub Actions workflows that pin references, Dependabot can update the versioning for calls to reusable workflows within workflow files. For more information, see “About Dependabot version updates.”
  • On an instance with GitHub Actions and the dependency graph enabled, as well as automatic access to GitHub.com actions using GitHub Connect, the web interface will suggest submission actions within a repository with supported languages. For more information, see the following documentation.
    • “Using the Dependency submission API“
    • “About GitHub Actions for enterprises“
    • “Enabling automatic access to GitHub.com actions using GitHub Connect“
    For repositories that use a language that has a submission action, when users with write access visit their dependency graph (this page), we will show them a prompt that directs them to the Marketplace to find an action that would help them.
  • To improve the security of projects that use npm v9, the dependency graph and Dependabot can parse and update package-lock.json files that specify lockfileVersion: 3. For more information, see “About the dependency graph,” “About Dependabot version updates,” and lockfileVersion in the npm documentation.
  • To improve the security of Gradle projects, the dependency graph and Dependabot can parse and update Gradle version catalogs in settings.gradle. For more information, see “About Dependabot version updates” and Sharing dependency versions between projects in the Gradle User Manual.
  • To ensure that users receive the most relevant and actionable alerts about dependency updates, repository administrators and organization owners can enable or disable Dependabot alerts for an individual repository or organization. For more information, see “Securing your repository” or “Securing your organization.”
  • If people with access to a repository do not interact with Dependabot security updates for over 90 days, Dependabot will pause automated pull request activity. For more information, see “About Dependabot security updates.”
  • To help users evaluate the stability risk of a dependency update, Dependabot can fetch release notes, changelogs, and commit history in pull requests that update Docker dependencies. For more information, see “Configuration options for the dependabot.yml file.”
  • To assist with software security and supply chain risk management, people with read access to a repository can export a software bill of materials (SBOM) for a repository’s dependency graph using the web interface or REST API. The SBOM adheres to the SPDX 2.3 specification. For more information, see “Using the Dependency submission API,” “Exporting a software bill of materials for your repository,” and The Software Package Data Exchange® (SPDX®) Specification Version 2.3 on the SPDX website.
  • The dependency graph can parse Python dependencies for pyproject.toml files that follow the PEP 621 standard. For more information, see “About the dependency graph” and PEP 621 – Storing project metadata in pyproject.toml in the Index of Python Enhancement Proposals.
  • Users can use the GraphQL API to review dependencies submitted using the Dependency submission API. For more information, see “Schema previews.”

• GitHub Actions
  • On instances in a cluster configuration, GitHub Actions is available as a private beta. Beta features are subject to change. For more information, and to enroll in the beta, contact your representative on GitHub’s Sales team.
  • Administrators of self-hosted runners for GitHub Actions can configure auto-scaling runners using Actions Runner Controller and runner scale sets. For more information, see “About Actions Runner Controller.”
  • Administrators can bypass all protection rules for a given environment and force the pending jobs referencing the environment to proceed. For more information, see “Using environments for deployment.”
  • Users who deploy with OIDC can define more advanced access policies by including additional custom claims within a token. To help uniquely verify the source of a workflow job, include the following claims.
    • actor_id
    • repository_id
    • repository_owner_id
    • workflow_ref
    • workflow_sha
    • job_workflow_sha
    For more information, see Security hardening your deployments.
  • To improve security for workflows that use GITHUB_TOKEN, the following defaults apply to new organizations and repositories.
    • New organizations that users create inherit permissions from the instance’s enterprise-level configuration. For more information, see “Disabling or limiting GitHub Actions for your organization.”
    • New repositories that users create within an organization inherit permissions from the organization. For more information, see “Managing GitHub Actions settings for a repository.”
    • New user-owned repositories have a read-only GITHUB_TOKEN. For more information, see “Managing GitHub Actions settings for a repository.”
  • To allow workflow authors to pin a required workflow file to a fully validated version, required workflows can be referenced using any branch, tag, or commit SHA from the repository containing the workflow file. For more information, see “Disabling or limiting GitHub Actions for your organization.”
  • To enforce required workflows throughout an organization, GitHub Enterprise Server blocks direct pushes to branches where required workflows are enforced. To allow direct pushes for a particular repository, remove the repository as a target for the required workflow. For more information, see “Disabling or limiting GitHub Actions for your organization.”
  • To improve performance for workflows that build Go, caching is enabled by default when using the setup-go action. For more information, see “Building and testing Go.”

• Organizations
  • Organization owners can improve security posture and protect data from threats by enabling the display of organization members’ IP addresses in audit log events. This feature is in beta and is subject to change. For more information, see “Displaying IP addresses in the audit log for your organization.”
  • To allow the management of branch protection rules without granting admin access, organization owners can create a custom role with the “Edit repository rules” permission. For more information, see “Managing custom repository roles for an organization.”
  • Users of the REST API can programmatically create and update least-privilege roles for repositories using the Custom Repository Roles REST API. The API is generally available, with a breaking change to the API’s endpoint paths. Previously, the API was accessible at /orgs/{org}/custom_roles, and is now accessible at /orgs/{org}/custom-repository-roles. The List custom repository roles in an organization will no longer be available in the next version of the REST API. For more information, see “About custom repository roles” and “Custom Repository Roles” in the REST API documentation.
  • Enterprise and organization owners can delete an organization and all of the organization’s repositories using the REST API. After deletion, organization names are locked for 90 days. For more information, see “Organizations” in the REST API documentation.

• Repositories
  • Within the “Insights” tab for a repository, the sidebar’s “Forks” tab provides more information about a project’s forks, including a sortable and filterable list of forks and more details about each fork.
  • Repository administrators can unarchive a repository using the REST API. For more information, see “Repositories” in the REST API documentation.
  • Projects
  • To visualize a project at a high level and across a configurable timespan, users can apply a roadmap layout to any project view. For more information, see “Changing the layout of a view.”
  • To get started with a new project faster, users can copy an existing project, including the source project’s views, custom fields, and draft issues. For more information, see “Copying an existing project.”
  • To save time when adding items to a project, users can configure a workflow to automatically add new items from a repository as people create or update items that match specific criteria. For more information, see “Adding items automatically.”
  • To keep a long-lived project focused, users can define filters to automatically archive items. For more information, see “Archiving items automatically.”
  • To easily organize items within a project’s columns while using the board layout, users can sort the project by field values using the view configuration menu. For more information, see “Customizing the board layout.”
  • To quickly add a new issue to a project without changing context, users can create a new issue from a project’s omnibar by clicking +, then clicking Create new issue. For more information, see “Adding items to your project.”
  • To help people scan a project and take action, users can add a color and a text description to each value for a project’s single select fields. For more information, see “About single select fields.”
  • Users of the GitHub CLI can manage projects from the command line. For more information, see “About GitHub CLI” and the README for the github/gh-projects repository on GitHub.com.
  • For users who programmatically access projects using the GraphQL API, additional mutations are available. For more information, see “createProjectV2Field,” “deleteProjectV2Field,” and “deleteProjectV2” in the “Mutations” GraphQL documentation.

• GitHub Discussions
  • To indicate that a discussion is resolved, outdated, or a duplicate, users can close the discussion. For more information, see “Managing discussions.”
  • To encourage other users to include specific, structured information in discussions, users can create discussion category forms. For more information, see “Creating discussion category forms.”
  • After a user locks a discussion and disallows further comments, the user can permit emoji reactions on the discussion. For more information, see “Moderating discussions.”

• Pull requests
  • To provide feedback on an entire file, or a file that’s been deleted, users can comment on a file from a pull request’s “Files changed” tab. For more information, see “Commenting on a pull request.”
  • Users of the GraphQL API can revert a merged pull request by using the revertPullRequest mutation. For more information, see “Reverting a pull request” and “Mutations” in the GraphQL API documentation.

Deprecations

• Only GitHub Actions can publish a GitHub Pages site if source includes symbolic links
  • To improve the security of an instance where users deploy sites using GitHub Pages, sites that contain symbolic links will no longer build outside of GitHub Actions. If a user’s site is affected and a site administrator has configured email for the instance, the user will receive an email with instructions about how to fix the error. To continue using symbolic links in the site’s source, the instance must be configured for GitHub Actions, and the user must write a GitHub Actions workflow to use as a publishing source. For more information, see “About GitHub Pages.”