GitHub AE est actuellement en version limitée.

GitHub AE release notes

GitHub AE 3.6

GitHub a commencé à déployer ces changements pour les entreprises le February 16, 2023.

3.6.0: Features

  • Administrator experience

  • Identity and access management

    • Custom repository roles are generally available. With custom repository roles, organization owners now have more granular control over the repository access permissions they can grant to users. Custom repository roles are also fully supported by the REST API. For more information, see "Managing custom repository roles for an organization" and "Organizations" in the REST API documentation.

  • Policies

  • GitHub Advanced Security

    • Users can opt to receive a webhook event that triggers when someone enables or disables a code security or analysis feature for an organization or repository. For more information, see the following documentation.

    • Enterprise owners and users can view secret scanning alerts and bypasses of secret scanning's push protection in the enterprise and organization audit logs, and via the REST API. For more information, see the following documentation.

    • Organization owners can now configure two new permissions for secret scanning when managing custom repository roles.

      • View secret scanning results
      • Dismiss or reopen secret scanning results

      For more information, see "Managing custom repository roles for an organization."

    • Users can execute a dry run of custom secret scanning patterns at the enterprise, organization, or repository level, depending on their access. Dry runs allow users to review and hone their patterns before publishing them and generating alerts. You can compose a pattern, then use Save and dry run to retrieve results. The scans typically take just a few seconds, but GitHub AE will also notify users via email when dry run results are ready. For more information, see "About secret scanning" and "Defining custom patterns for secret scanning."

    • Users can enable secret scanning for archived repositories using the UI or API. For more information, see "About secret scanning," "About archived repositories," and "Repositories" in the REST API documentation.

    • Secret scanning prevents the leak of secrets in the web editor. For more information, see "Protecting pushes with secret scanning."

    • Code scanning now detects a larger number of CWEs, and CodeQL code scanning fully supports the standard language features in the following language releases.

      • C# 10 / .NET 6
      • Python 3.10
      • Java 17
      • TypeScript 4.5

      For more information, see the GitHub Blog.

    • Organization owners and security managers can view code scanning alerts in an organization's Security tab. For more information, see "About the security overview."

    • The code scanning alert page now always shows the alert status and information for the default branch. There is a new "Affected branches" panel in the sidebar where you can see the status of the alert in other branches. If the alert does not exist in your default branch, the alert page will show the status as "In branch" or "In pull request" for the location where the alert was last seen. This improvement makes it easier to understand the status of alerts which have been introduced into the code base. For more information, see "About code scanning alerts." The alert list page is not changed and can be filtered by branch. You can use the code scanning API to retrieve more detailed branch information for alerts. For more information, see "Code Scanning" in the REST API documentation.

    • Code scanning now shows the details of the analysis origin of an alert. If an alert has more than one analysis origin, it is shown in the "Affected branches" sidebar and in the alert timeline. Users can hover over the analysis origin icon in the "Affected branches" sidebar to see the alert status in each analysis origin. If an alert only has a single analysis origin, no information about analysis origins is displayed on the alert page. These improvements will make it easier to understand alerts. In particular, it will help users understand those that have multiple analysis origins. This is especially useful for setups with multiple analysis configurations, such as monorepos. For more information, see "About code scanning alerts."

    • Users can use sort and direction parameters in the REST API when retrieving secret scanning alerts, and sort based on the alert’s created or updated fields. The new parameters are available for all of your GitHub AE deployment, or for individual organizations or repositories. For more information, see the following documentation.

    • Users can opt to receive a webhook that triggers when a secret is detected in a new location. The secret_scanning_alert_location webhook event includes location details, like the commit SHA, and the associated alert for the detection. A location is created for every new file path containing the detected secret. For more information, see "Webhook events and payloads."

    • Users can optionally add a comment when dismissing a code scanning alert in the web UI or via the REST API. Dismissal comments appear in the event timeline. Users can also add or retrieve a dismissal comment via the REST API. For more information, see "Triaging code scanning alerts in pull requests" and "Code Scanning" in the REST API documentation.

    • Users can now retrieve code scanning alerts for an organization using the REST API. This new API endpoint supplements the existing endpoint for repositories. For more information, see "Code Scanning" in the REST API documentation.

    • The contents of the github/codeql-go repository have moved to the github/codeql repository, to live alongside similar libraries for all other programming languages supported by CodeQL. The open-source CodeQL queries, libraries, and extractor for analyzing codebases written in the Go programming language with GitHub's CodeQL code analysis tools can now be found in the new location. For more information, including guidance on migrating your existing workflows, see github/codeql-go#741.

  • Dependabot

    • Enterprise owners can see an overview of Dependabot alerts across the GitHub AE deployment, including a repository-centric view of application security risks, and an alert-centric view of all secret scanning and Dependabot alerts. The views are in beta and subject to change. For more information, see "Viewing the security overview."

    • Organization owners and security managers can view Dependabot alerts in an organization's Security tab. For more information, see "About the security overview."

    • Users can reopen a dismissed Dependabot alert using the web UI. This does not affect Dependabot pull requests or the GraphQL API. For more information, see "About Dependabot alerts."

    • Users can view fixed alerts from Dependabot with the GraphQL API. Users can also access and filter by state, as well as by unique numeric identifier, and filter by state on the vulnerability alert object. The following fields now exist for a RepositoryVulnerabilityAlert.

      • number
      • fixed_at
      • fix_reason
      • state

      For more information, see "Objects" in the GraphQL API documentation.

  • Code security

    • Organization owners and security managers can use the security overview for an organization to view a repository-centric view of application security risks, or an alert-centric view of all code scanning, Dependabot, and secret scanning alerts for all repositories in an organization. For more information, see "About the security overview."

    • GitHub Actions can enforce dependency reviews on users' pull requests by scanning for dependencies, and will warn users about associated security vulnerabilities. The dependency-review-action action is supported by a new API endpoint that diffs the dependencies between any two revisions. For more information, see "About dependency review."

    • The dependency graph detects YAML files for GitHub Actions workflows. GitHub AE will display the workflow files within the Insights tab's dependency graph section. Repositories that publish actions will also be able to see the number of repositories that depend on that action from the "Used By" control on the repository homepage. For more information, see "About the dependency graph."

    • The dependency graph detects Cargo.toml and Cargo.lock files for Rust. These files will be displayed in the Dependency graph section of the Insights tab. Users will receive Dependabot alerts and updates for vulnerabilities associated with their Rust dependencies. Package metadata, including mapping packages to repositories, will be added at a later date. For more information, see "About the dependency graph."

    • If GitHub Connect is enabled for GitHub AE, users can contribute an improvement to a security advisory in the GitHub Advisory Database. To contribute, click Suggest improvements for this vulnerability while viewing an advisory's details. For more information, see the following articles.

  • GitHub Actions

    • People who maintain self-hosted runners now have more control over when the runners perform software updates. If you specify the --disableupdate flag to the runner, the runner will not try to perform an automatic software update if a newer version of the runner software is available. This allows updates to the self-hosted runner on a custom schedule, and is especially convenient if a self-hosted runner is in a container. For compatibility with the GitHub Actions service, runner software must be updated within 30 days of a new runner version being available. For more information about installation of the latest runner version, see the installation instructions for the latest release in actions/runner.

    • When using GitHub Actions, to reduce the risk of merging a change that was not reviewed by another person into a protected branch, enterprise owners and repository administrators can prevent Actions from creating pull requests. Organization owners could previously enable this restriction. For more information, see the following articles.

    • Organization owners can increase the security of CI/CD workflows on self-hosted runners by choosing which workflows can access a runner group. Previously, any workflow in a repository, such as an issue labeler, could access the self-hosted runners available to an organization. For more information, see "Managing access to self-hosted runners using groups" and the GitHub Blog.

    • Organization owners can control whether GitHub Actions can approve pull requests. This feature protects against a user using GitHub Actions to satisfy the "Required approvals" branch protection requirement and merging a change that was not reviewed by another user. To prevent breaking existing workflows, Allow GitHub Actions reviews to count towards required approval is enabled by default. Organization owners can disable the feature in the organization's GitHub Actions settings. For more information, see "Disabling or limiting GitHub Actions for your organization."

    • Users can write a single workflow triggered by workflow_dispatch and workflow_call, and use the inputs context to access input values. Previously, workflow_dispatch inputs were in the event payload, which increased difficulty for workflow authors who wanted to write one workflow that was both reusable and manually triggered. For workflows triggered by workflow_dispatch, inputs are still available in the github.event.inputs context to maintain compatibility. For more information, see "Contexts."

    • Users can now re-run only failed jobs or an individual job in a GitHub Actions workflow run. For more information, see "Re-running workflows and jobs."

    • To summarize the result of a job, users can generate Markdown and publish the contents as a job summary. For example, after running tests with GitHub Actions, a summary can provide an overview of passed, failed, or skipped tests, potentially reducing the need to review the full log output. For more information, see "Workflow commands for GitHub Actions."

    • To more easily diagnose job execution failures during a workflow re-run, users can enable debug logging, which outputs information about a job's execution and environment. For more information, see "Re-running workflows and jobs" and "Using workflow run logs."

    • If you manage self-hosted runners for GitHub Actions, you can ensure a consistent state on the runner itself before and after a workflow run by defining scripts to execute. By using scripts, you no longer need to require that users manually incorporate these steps into workflows. Pre- and post-job scripts are in beta and subject to change. For more information, see "Running scripts before or after a job."

  • Community experience

  • Organizations

    • Organization owners can pin a repository to an organization's profile directly from the repository via the new Pin repository dropdown.

  • Repositories

    • While creating a fork, users can customize the fork's name. For more information, see "Fork a repo."

    • Users can delete a branch that's associated with an open pull request. For more information, see "Creating and deleting branches within your repository."

    • CODEOWNERS has received the following improvements.

      • Syntax errors are now surfaced when viewing a CODEOWNERS file from the web UI. Previously, when a line in a CODEOWNERS file had a syntax error, the error would be ignored or in some cases cause the entire CODEOWNERS file to not load. GitHub Apps and Actions can access the same list of errors using new REST and GraphQL APIs. For more information, see "Repositories" in the REST API documentation or "Objects" in the GraphQL API documentation.
      • After someone creates a new pull request or pushes new changes to a draft pull request, any code owners that will be requested for review are now listed in the pull request under "Reviewers". This feature gives you an early look at who will be requested to review once the pull request is marked ready for review.
      • Comments in CODEOWNERS files can now appear at the end of a line, not just on dedicated lines.

      For more information, see "About code owners."

    • When a user renames or moves a file to a new directory, if at least half of the file's contents are identical, the commit history indicates that the file was renamed, similar to git log --follow. For more information, see the GitHub Blog.

    • Users can require a successful deployment of a branch before anyone can merge the pull request associated with the branch. For more information, see "About protected branches" and "Managing a branch protection rule."

    • Repository administrators can now configure tag protection rules to protect a repository's tags. Once protected by a tag protection rule, tags matching a specified name pattern can only be created and deleted by users with maintain or admin access to the repository. For more information, see "Configuring tag protection rules."

    • Users can ignore revisions in the blame view by creating a .git-blame-ignore-revs file in the root of a repository. For more information, see "Viewing a file."

    • Users can grant exceptions to GitHub Apps for any branch protection rule that supports exceptions. For more information, see "About apps" and "Managing a branch protection rule."

  • Commits

  • Pull requests

    • Using the file tree located in the Files changed tab of a pull request, users can navigate modified files, understand the size and scope of changes, and focus reviews. The file tree appears if a pull request modifies at least two files, and the browser window is sufficiently wide. For more information, see "Reviewing proposed changes in a pull request" and "Filtering files in a pull request."

    • Users can default to using pull requests titles as the commit message for all squash merges. For more information, see "Configuring commit squashing for pull requests."

    • The Update branch button on the pull request page lets users update a pull request's branch with the latest changes from the base branch. This is useful for verifying that the pull request's changes are compatible with the current version of the base branch before you merge. Two enhancements provide more ways to keep a branch up to date.

      • When a pull request's topic branch is out of date with the base branch, users can update the branch by rebasing on the latest version of the base branch. Rebasing applies the changes from the topic branch onto the latest version of the base branch, resulting in a branch with a linear history since no merge commit is created. To update by rebasing, click the drop-down menu next to the Update Branch button, click Update with rebase, and then click Rebase branch. Previously, Update branch performed a traditional merge that always resulted in a merge commit in your pull request branch. This option is still available, but now users have the choice. For more information, see "Keeping your pull request in sync with the base branch."
      • A new repository setting allows the Update branch button to always be available when a pull request's topic branch is not up to date with the base branch. Previously, this button was only available when the Require branches to be up to date before merging branch protection setting was enabled. People with admin or maintainer access can manage the Always suggest updating pull request branches setting from the Pull Requests section in repository settings. For more information, see "Managing suggestions to update pull request branches."

  • Releases

    • When viewing the details for a particular release, users can see the creation date for each release asset. For more information, see "Viewing your repository's releases and tags."

    • While creating a release with automatically generated release notes, users can see the tag identified as the previous release, then choose to select a different tag to specify as the previous release. For more information, see "Automatically generated release notes."

  • Gist

    • Gists now only show the 30 most recent comments when first displayed. Users can click Load earlier comments... to view more. This allows gists that have many comments to appear more quickly. For more information, see "Editing and sharing content with gists."

  • Markdown

    • Editing Markdown in the web interface has been improved.

      • After a user selects text and pastes a URL, the selected text will become a Markdown link to the pasted URL.
      • When a user pastes spreadsheet cells or HTML tables, the resulting text will render as a table.
      • When a user copies text containing links, the pasted text will include the link as a Markdown link.

      For more information, see "Basic writing and formatting syntax."

    • When editing a Markdown file in the web interface, clicking the Preview tab will automatically scroll to the place in the preview that you were editing. The scroll location is based on the position of the cursor before clicking the Preview tab.

  • Accessibility

    • A light high-contrast theme, with greater contrast between foreground and background elements, is now available. For more information, see "Managing your theme settings."

3.6.0: Changes

  • Lists of repositories owned by a user or organization now have an additional filter option, "Templates", making it easier to find template repositories.

  • GitHub AE can display several common image formats, including PNG, JPG, GIF, PSD, and SVG, and provides several ways to compare differences between versions. When reviewing added or changed images in a pull request, previews of those images are now shown by default. Previously, users would see a message indicating that binary files could not be shown, and would need to toggle the "Display rich diff" option. For more information, see "Working with non-code files."

  • Settings pages for users, organizations, repositories, and teams have been redesigned, grouping similar settings pages into sections for improved information architecture and discoverability. For more information, see the GitHub Changelog.

  • Interactive elements in the web interface such as links and buttons show a visible outline when focused with a keyboard, to help users find the current position on a page. In addition, when focused, form fields have a higher contrast outline.

  • Focusing or hovering over a label now displays a tooltip with the label's description.

  • If a user refreshes the page while creating a new issue or pull request, the assignees, reviewers, labels, and projects will all be preserved.

  • To use the device authorization flow for OAuth and GitHub Apps, app authors must manually enable the feature. This change reduces the likelihood of apps being used in phishing attacks against GitHub AE users by ensuring integrators are aware of the risks and make a conscious choice to support this form of authentication. Users who own or manage an OAuth App or GitHub App and want to use the device flow can enable it for an app via the app's settings page. The device flow API endpoints will respond with status code 400 to apps that have not enabled this feature. For more information, see "Authorizing OAuth Apps."

3.6.0: Deprecations

GitHub AE 3.4

GitHub a commencé à déployer ces changements pour les entreprises le October 25, 2022.

3.4.0: Features

  • Security & access management

    • Users with admin access to a repository can better understand who has access to the repository, see what level of access each user has, and more easily manage access to the repository. For example, users can accomplish the following tasks.

      • Search all members, teams, and collaborators who have access to the repository.
      • View when members have mixed role assignments, granted to them directly as individuals or indirectly via a team: a new "mixed roles" warning displays the highest level role the user is granted if their access is higher than their assigned role.

      For more information, see "Managing teams and people with access to your repository."

  • Administration

    • Enterprise owners can now show additional links to enterprise members and collaborators in a custom footer. For more information, see "Configuring custom footers."

  • GitHub Actions

    • Users can reuse a workflow with a single line of configuration. Reusable workflows save time and maintenance by removing the need to copy and paste workflow definitions across repositories. Reusable workflows are in beta and subject to change. For more information, see "Reusing workflows."

    • The updated management experience for self-hosted runners simplifies management of runner groups and provides an improved overview of your runners. For more information, see "About self-hosted runners" and "Managing access to self-hosted runners using groups."

    • Dependabot now shares secrets with GitHub Actions when Dependabot triggers a workflow run, so users can now pull from private package registries within CI pipelines using Dependabot's secrets. For more information, see "Managing encrypted secrets for Dependabot."

    • Users can use an if conditional to prevent specific steps in a composite action from executing unless a condition is met. Like steps defined in workflows, you can use any supported context and expression to create a conditional. For more information about composite actions, see "Creating a composite action."

    • Users can provide a better experience to users of a workflow by specifying input types for manually triggered workflows. Workflows now support choice, boolean, and environment. For more information, see "Workflow syntax for GitHub Actions."

    • The first available matching runner at the repository, organization, or enterprise level will run each job in all cases, which means jobs are sent to self-hosted runners much faster, especially for organizations and enterprises with many self-hosted runners. Previously, when running a job that required a self-hosted runner, GitHub Actions would look for self-hosted runners in the repository, organization, and enterprise, in that order. For more information, see "Using self-hosted runners in a workflow."

    • Users can specify that a JavaScript action should run in Node.js 16 by specifying runs.using as node16. Node.js 16 support supplements the existing support for Node.js 12. Runners must have version 2.285.0 or later of the GitHub Actions Runner installed. For more information, see "Metadata syntax for GitHub Actions" and the actions/runner repository.

    • Users can add, list, and remove labels for self-hosted runners using the REST API. For more information, see "Self-hosted runners" in the REST API documentation.

  • GitHub Advanced Security

    • Users can improve the security of services and tools created with Ruby using CodeQL code scanning. For all common Ruby versions up to and including 3.02, CodeQL can detect common issues such as SQL injection, ReDoS, OS command and argument injection, XML entity expansion, reflected cross-site scripting (XSS), stored XSS, unsafe deserialization, and hard-coded credentials. To enable Ruby analysis, users must update an existing CodeQL code scanning workflow file. Ruby support for CodeQL is in beta and subject to change. For more information, see "Configuring code scanning" and the CodeQL documentation. For more information about code scanning with CodeQL, see "About code scanning with CodeQL."

    • CodeQL's Python analysis supports additional frameworks and can detect more potential sources of untrusted user data, steps through which that data flows, and potentially dangerous sinks in which this data could end up. For more information, see "Supported languages and frameworks" in the CodeQL documentation.

    • Users can retrieve commit details of secrets detected in private repository scans using the REST API. The new endpoint will surface details of a secret's first detection within a file, including the secret's location and commit SHA. For more information, see "About secret scanning" and "Secret scanning" in the REST API documentation.

    • The code scanning API includes the following improvements.

      • Alerts include the fixed_at timestamp, which is the first time that the alert was not detected in an analysis. Users can use this data to better understand when code scanning alerts are being fixed.
      • Users can sort for the most important alert results using sort and direction on either created, updated, or number. For more information, see Code scanning in the REST API documentation.
      • The alerts and alert endpoint response include a Last-Modified header. For more information, see Last-Modified in the Mozilla documentation.
      • SARIF responses for code scanning analyses include relatedLocations, which may contain locations which are not the primary location of the alert. For an example, see the SARIF spec. For more information, see Code scanning in the REST API documentation.
      • The webhook response alert rule object includes help and tags data. For more information, see "Webhook events and payloads."

    • Organization owners and security managers can retrieve private repositories' secret scanning results at the enterprise level using the REST API. For more information, see "About secret scanning" and "Secret scanning" in the REST API documentation.

  • Dependabot

    • Users can dismiss Dependabot alerts via the GraphQL API. For more information, see "Mutations" in the GraphQL API documentation.

  • Code security

    • Dependency graph detects Python dependencies in repositories that use the Poetry package manager. Dependencies will be detected from both pyproject.toml and poetry.lock manifest files. For more information, see "About the dependency graph."

    • Developers and security researchers can use CodeQL to build databases and analyze code on machines powered by Apple silicon chips, such as the M1. Both the CodeQL CLI and VS Code extension support Apple silicon. To use the CodeQL CLI or the VS Code extension on Apple silicon, users must install the Xcode command-line developer tools and Rosetta 2. CodeQL support for Apple silicon is in beta and subject to change.

    • Users of the CodeQL CLI versions 2.7.1 and later can include query help in SARIF files as Markdown, and the help text will appear in GitHub AE's code scanning UI. Users can include query help as a Markdown file with the same name as the corresponding query file. For example, if your query file is MyCustomQuery.ql, the name of the query help file would be MyCustomQuery.md. For more information about authorship of query help for custom CodeQL queries, see the query help style guide.

      • Users who don't use GitHub Actions for CI/CD and code scanning must specify the addition of query help when running the codeql database analyze command by including the --sarif-add-query-help flag. For more information, see "Analyzing databases with the CodeQL CLI" in the CodeQL documentation.

  • Notifications

    • Users can unsubscribe from all repositories owned by a given user or organization. For more information, see "Managing your subscriptions."

    • Organization owners can unsubscribe from email notifications when new deploy keys are added to repositories belonging to their organizations. For more information, see "Configuring notifications."

    • The subject line for email notifications for issues and pull requests includes "(Issue #NUMBER)" or "(PR #NUMBER)" to help users easily distinguish between the two notification types.

    • The View on GitHub link at the bottom of email notifications is no longer hidden by default in Gmail.

  • Organizations

    • Organization members can now view a list of enterprise owners. Whenever an organization member encounters a prompt to contact an enterprise owner, a link will direct the user to the list. The list is also accessible using the GraphQL API's Organization object at the enterpriseOwners endpoint. For more information, see "Viewing people's roles in an organization."

  • Repositories

  • Pull requests

    • Users can enable Only notify requested team members independently of Enable auto assignment in the team's code review settings, allowing users to require the team for review, but without always notifying the whole team unnecessarily. For more information, see "Managing code review settings for your team."

  • Releases

    • The releases UI is improved, providing clarity into what's included in a given release and recognition for contributors to the release. Pagination is improved, and new search functionality is available.

    • Users can automatically generate release notes that include a summary of all the pull requests for a given release. For more information, see "Automatically generated release notes."

  • Gists

    • Users can preview renderings of Markdown files in gists. When creating or editing a gist file with the Markdown file extension, .md, a Preview or Preview changes tab will display a Markdown rendering of the file's contents. For more information about gists, see "Editing and sharing content with gists."

  • Markdown

    • Users can choose to use a fixed-width font in Markdown fields, like comments on issues and pull requests. For more information, see "About writing and formatting on GitHub."

    • Users can specify the theme an image is displayed for in Markdown. For more information, see "Basic writing and formatting syntax."

    • Users can quickly create a Markdown link while editing text in Markdown-enabled fields like issue or pull request comments by selecting text and then pasting a URL.

    • HTML links that users paste into Markdown fields are automatically converted into Markdown links. To paste HTML links as plain text, press ⌘/ctrl + shift + v.

    • Right-to-left languages are supported natively in Markdown files and comments in issues, pull requests, and discussions.

  • Developer experience

  • Accessibility

    • Users can manage keyboard shortcuts with GitHub AE's new accessibility settings, and can choose to disable character key shortcuts that only use single characters, such as s, g c, and . (the period key). For more information, see "Managing accessibility settings."

  • GitHub Apps

    • To ensures all changes are validated by the intended app, users can now control which GitHub App a required status check is provided by. If status is then provided by a different app or by a user via a commit status, merging will be prevented. Existing required status checks will continue to accept status from any app, but can be updated to only accept status from a specific app. Newly-added required status checks will default to the app that most recently reported the status, but you can choose a different app or allow any app to provide the status. For more information, see "About protected branches" and "Editing a branch protection rule."

  • Webhooks

    • Organization owners and users with admin access to a repository can trigger webhooks to listen for changes to branch protection rules. For more information, see "Webhook events and payloads."

3.4.0: Changes

  • When users are invited to a private repository, navigating to the private repository's URL will display a prompt to join the repository instead of a 404 error.

  • Invitations to private repositories appear in notifications.

  • When a user types @ in the web UI to mention a user, the list ranks participants in issues, pull requests, and discussions higher so that it's more likely the person a user is looking for will be listed first.

  • To prevent potentially malicious code from executing in a privileged workflow, the following changes apply to GitHub Actions workflows triggered by Dependabot.

    • Workflow runs triggered for the create, deployment, and deployment_status events will always receive a read-only token and no secrets. - Workflow runs triggered for the pull_request_target event on pull requests where the base ref was created by Dependabot will always receive a read-only token and no secrets. - Workflow runs on push and pull_request events triggered by Dependabot respect the permissions specified in your workflows. The default token permissions will remain read-only.

  • The setting to hide whitespace changes in a pull request's Files changed tab is preserved for each pull request.

  • The "Update a pull request branch" API for GitHub Apps now requires the calling user or application to have write access to the head repository. If the caller does not have write access, the API will return a 403 Forbidden response. For more information, see "Pulls" in the REST API documentation.

GitHub AE 3.3

GitHub a commencé à déployer ces changements pour les entreprises le May 17, 2022.

3.3.0: Features

  • GitHub Advanced Security features are generally available

  • View all code scanning alerts for a pull request

    • You can now find all code scanning alerts associated with your pull request with the new pull request filter on the code scanning alerts page. The pull request checks page shows the alerts introduced in a pull request, but not existing alerts on the pull request branch. The new "View all branch alerts" link on the Checks page takes you to the code scanning alerts page with the specific pull request filter already applied, so you can see all the alerts associated with your pull request. This can be useful to manage lots of alerts, and to see more detailed information for individual alerts. For more information, see "Managing code scanning alerts for your repository."

  • Security overview for organizations

    • GitHub Advanced Security now offers an organization-level view of the application security risks detected by code scanning, Dependabot, and secret scanning. The security overview shows the enablement status of security features on each repository, as well as the number of alerts detected.

      In addition, the security overview lists all secret scanning alerts at the organization level. Similar views for Dependabot and code scanning alerts are coming in future releases. For more information, see "About the security overview."

      Screenshot of security overview

  • Dependency graph

    • Dependency graph is now available on GitHub AE. The dependency graph helps you understand the open source software that you depend on by parsing the dependency manifests checked into repositories. For more information, see "About the dependency graph."

  • Dependabot alerts

    • Dependabot alerts can now notify you of vulnerabilities in your dependencies on GitHub AE. You can enable Dependabot alerts by enabling the dependency graph, enabling GitHub Connect, and syncing vulnerabilities from the GitHub Advisory Database. This feature is in beta and subject to change. For more information, see "About Dependabot alerts."

      After you enable Dependabot alerts, members of your organization will receive notifications any time a new vulnerability that affects their dependencies is added to the GitHub Advisory Database or a vulnerable dependency is added to their manifest. Members can customize notification settings. For more information, see "Configuring notifications for % data variables.product.prodname_dependabot_alerts %}."

  • Security manager role for organizations

    • Organizations can now grant teams permission to manage security alerts and settings on all their repositories. The "security manager" role can be applied to any team and grants the team's members the following permissions.

      • Read access on all repositories in the organization
      • Write access on all security alerts in the organization
      • Access to the organization-level security tab
      • Write access on security settings at the organization level
      • Write access on security settings at the repository level

      For more information, see "Managing security managers in your organization."

  • Ephemeral runners and autoscaling webhooks for GitHub Actions

    • GitHub AE now supports ephemeral (single job) self-hosted runners and a new workflow_job webhook to make autoscaling runners easier.

      Ephemeral runners are good for self-managed environments where each job is required to run on a clean image. After a job is run, GitHub AE automatically unregisteres ephemeral runners, allowing you to perform any post-job management.

      You can combine ephemeral runners with the new workflow_job webhook to automatically scale self-hosted runners in response to job requests from GitHub Actions.

      For more information, see "Autoscaling with self-hosted runners" and "Webhook events and payloads."

  • Composite actions for GitHub Actions

    • You can reduce duplication in your workflows by using composition to reference other actions. Previously, actions written in YAML could only use scripts. For more information, see "Creating a composite action."

  • New token scope for management of self-hosted runners

    • Managing self-hosted runners at the enterprise level no longer requires using personal access tokens with the admin:enterprise scope. You can instead use the new manage_runners:enterprise scope to restrict the permissions on your tokens. Tokens with this scope can authenticate to many REST API endpoints to manage your enterprise's self-hosted runners.

  • Audit log accessible via REST API

    • You can now use the REST API to programmatically interface with the audit log. While audit log forwarding provides you with the ability to retain and analyze data with your own toolkit and determine patterns over time, the new REST API will help you perform limited analysis on events of note that have happened in recent history. For more information, see "Reviewing the audit log for your organization."

  • Expiration dates for personal access tokens

    • You can now set an expiration date on new and existing personal access tokens. GitHub AE will send you an email when it's time to renew a token that's about to expire. Tokens that have expired can be regenerated, giving you a duplicate token with the same properties as the original. When using a token with the GitHub AE API, you'll see a new header, GitHub-Authentication-Token-Expiration, indicating the token's expiration date. You can use this in scripts, for example to log a warning message as the expiration date approaches. For more information, see "Creating a personal access token" and "Getting started with the REST API."

  • Export a list of people with access to a repository

  • Improved management of code review assignments

    • New settings to manage code review assignment code review assignment help distribute a team's pull request review across the team members so reviews aren't the responsibility of just one or two team members.

      • Child team members: Limit assignment to only direct members of the team. Previously, team review requests could be assigned to direct members of the team or members of child teams.
      • Count existing requests: Continue with automatic assignment even if one or more members of the team are already requested. Previously, a team member who was already requested would be counted as one of the team's automatic review requests.
      • Team review request: Keep a team assigned to review even if one or more members is newly assigned.

      For more information, see "Managing code review settings for your team."

  • New themes

    • Two new themes are available for the GitHub AE web UI.

      • A dark high contrast theme, with greater contrast between foreground and background elements
      • Light and dark colorblind, which swap colors such as red and green for orange and blue

      For more information, see "Managing your theme settings."

  • Markdown improvements

    • You can now use footnote syntax in any Markdown field to reference relevant information without disrupting the flow of your prose. Footnotes are displayed as superscript links. Click a footnote to jump to the reference, displayed in a new section at the bottom of the document. For more information, see "Basic writing and formatting syntax."

    • You can now toggle between the source view and rendered Markdown view through the web UI by clicking the button to "Display the source diff" at the top of any Markdown file. Previously, you needed to use the blame view to link to specific line numbers in the source of a Markdown file.

    • GitHub AE now automatically generates a table of contents for Wikis, based on headings.

3.3.0: Changes

  • Performance

    • Page loads and jobs are now significantly faster for repositories with many Git refs.

  • Administration

    • The user impersonation process is improved. An impersonation session now requires a justification for the impersonation, actions are recorded in the audit log as being performed as an impersonated user, and the user who is impersonated will receive an email notification that they have been impersonated by an enterprise owner. For more information, see "Impersonating a user."

  • GitHub Actions

    • To mitigate insider man-in-the-middle attacks when using actions resolved through GitHub Connect to GitHub.com from GitHub AE, GitHub AE retires the actions namespace (OWNER/NAME) on use. Retiring the namespace prevents that namespace from being created in your enterprise, and ensures all workflows referencing the action will download it from GitHub.com. For more information, see "Enabling automatic access to GitHub.com actions using GitHub Connect."

    • The audit log now includes additional events for GitHub Actions. GitHub AE now records audit log entries for the following events.

      • A self-hosted runner is registered or removed.
      • A self-hosted runner is added to a runner group, or removed from a runner group.
      • A runner group is created or removed.
      • A workflow run is created or completed.
      • A workflow job is prepared. Importantly, this log includes the list of secrets that were provided to the runner.

      For more information, see "Security hardening for GitHub Actions."

  • GitHub Advanced Security

    • Code scanning will now map alerts identified in on:push workflows to show up on pull requests, when possible. The alerts shown on the pull request are those identified by comparing the existing analysis of the head of the branch to the analysis for the target branch that you are merging against. Note that if the pull request's merge commit is not used, alerts can be less accurate when compared to the approach that uses on:pull_request triggers. For more information, see "About code scanning with CodeQL."

      Some other CI/CD systems can exclusively be configured to trigger a pipeline when code is pushed to a branch, or even exclusively for every commit. Whenever such an analysis pipeline is triggered and results are uploaded to the SARIF API, code scanning will try to match the analysis results to an open pull request. If an open pull request is found, the results will be published as described above. For more information, see "Uploading a SARIF file to GitHub."

    • GitHub AE now detects secrets from additional providers. For more information, see "Secret scanning patterns."

  • Pull requests

    • The timeline and Reviewers sidebar on the pull request page now indicate if a review request was automatically assigned to one or more team members because that team uses code review assignment.

      Screenshot of indicator for automatic assignment of code review

    • You can now filter pull request searches to only include pull requests you are directly requested to review by choosing Awaiting review from you. For more information, see "Searching issues and pull requests."

    • If you specify the exact name of a branch when using the branch selector menu, the result now appears at the top of the list of matching branches. Previously, exact branch name matches could appear at the bottom of the list.

    • When viewing a branch that has a corresponding open pull request, GitHub AE now links directly to the pull request. Previously, there would be a prompt to contribute using branch comparison or to open a new pull request.

    • You can now click a button to copy the full raw contents of a file to the clipboard. Previously, you would need to open the raw file, select all, and then copy. To copy the contents of a file, navigate to the file and click in the toolbar. Note that this feature is currently only available in some browsers.

    • A warning is now displayed when viewing a file that contains bidirectional Unicode text. Bidirectional Unicode text can be interpreted or compiled differently than it appears in a user interface. For example, hidden bidirectional Unicode characters can be used to swap segments of text in a file. For more information about replacing these characters, see the GitHub Changelog.

  • Repositories

    • GitHub AE now includes enhanced support for CITATION.cff files. CITATION.cff files are plain text files with human- and machine-readable citation information. GitHub AE parses this information into convenient formats such as APA and BibTeX that can be copied by others. For more information, see "About CITATION files."

    • You can now add, delete, or view autolinks through the Repositories API's Autolinks endpoint. For more information, see "Autolinked references and URLs" and "Repositories" in the REST API documentation.

  • Releases

  • Markdown

    • When dragging and dropping files such as images and videos into a Markdown editor, GitHub AE now uses the mouse pointer location instead of the cursor location when placing the file.

  • REST API

    • REST API previews have now graduated and are an official part of the API. Preview headers are no longer required for REST API endpoints, but will still function as expected if you continue to specify a graduated preview in the Accept header of a request.

GitHub AE 3.2

GitHub a commencé à déployer ces changements pour les entreprises le December 06, 2021.

3.2.0: Features

  • Administration

    • Customers with active or trial subscriptions for GitHub AE can now provision GitHub AE resources from the Azure Portal. Your Azure subscription must be feature-flagged to access GitHub AE resources in the portal. Contact your account manager or GitHub's Sales team to validate your Azure subscription's eligibility. For more information, see "Déploiement de GitHub AE."

  • GitHub Actions

    • GitHub Actions is now generally available for GitHub AE. GitHub Actions is a powerful, flexible solution for CI/CD and workflow automation. For more information, see "Comprendre GitHub Actions."

    • Self-hosted runners are the default type of runner system on GitHub AE, and are now generally available for GitHub Actions. With self-hosted runners, you can manage your own machines or containers for the execution of GitHub Actions jobs. For more information, see "About self-hosted runners" and "Ajout d’exécuteurs auto-hébergés."

    • Environments, environment protection rules, and environment secrets are now generally available for GitHub Actions on GitHub AE. For more information, see "Utilisation d’environnements pour le déploiement."

    • GitHub Actions can now generate a visual graph of your workflow on every run. With workflow visualization, you can achieve the following.

      • View and understand complex workflows.
      • Track progress of workflows in real-time.
      • Troubleshoot runs quickly by easily accessing logs and jobs metadata.
      • Monitor progress of deployment jobs and easily access deployment targets.

      For more information, see "Using the visualization graph."

    • GitHub Actions now lets you control the permissions granted to the GITHUB_TOKEN secret. The GITHUB_TOKEN is an automatically generated secret that lets you make authenticated calls to the API for GitHub AE in your workflow runs. GitHub Actions generates a new token for each job and expires the token when a job completes. The token has write permissions to a number of API endpoints except in the case of pull requests from forks, which are always read. These new settings allow you to follow a principle of least privilege in your workflows. For more information, see "Authentication in a workflow."

    • GitHub Actions now supports skipping push and pull_request workflows by looking for some common keywords in your commit message.

    • GitHub CLI 1.9 and later allows you to work with GitHub Actions in your terminal. For more information, see the GitHub Blog.

  • Code scanning

  • Secret scanning

    • You can now specify your own patterns for secret scanning with the beta of custom patterns on GitHub AE. You can specify patterns for repositories, organizations, and your entire enterprise. When you specify a new pattern, secret scanning searches a repository's entire Git history for the pattern, as well as any new commits. For more information, see "Defining custom patterns for secret scanning."

  • GitHub Connect

    • GitHub Connect is now available in beta for GitHub AE. GitHub Connect brings the power of the world's largest open source community to your enterprise. You can allow users to view search results from GitHub.com on GitHub AE, show contribution counts from GitHub AE on GitHub.com, and use GitHub Actions from GitHub.com. For more information, see "Managing connections between your enterprise accounts."

  • GitHub Packages

    • You can now delete any package or package version for GitHub Packages from GitHub AE's web UI. You can also undo the deletion of any package or package version within 30 days. For more information, see "Deleting and restoring a package."

    • The npm registry for GitHub Packages and GitHub.com no longer returns a time value in metadata responses, providing substantial performance improvements. GitHub will continue returning the time value in the future.

  • Audit logging

    • Events for pull requests and pull request reviews are now included in the audit log for both enterprises and organizations. These events help administrators better monitor pull request activity and ensure security and compliance requirements are being met. Events can be viewed from the web UI, exported as CSV or JSON, or accessed via REST API. You can also search the audit log for specific pull request events.

    • Additional events for GitHub Actions are now included in the audit log for both enterprises and organizations.

      • A workflow is deleted or re-run.
      • A self-hosted runner's version is updated.

  • Authentication

    • GitHub AE now officially supports Okta for SAML single sign-on (SSO) and user provisioning with SCIM. You can also map groups in Okta to teams on GitHub AE. For more information, see "Configuring authentication and provisioning for your enterprise using Okta" and "Mapping Okta groups to teams."

    • The format of authentication tokens for GitHub AE has changed. The change affects the format of personal access tokens and access tokens for OAuth Apps, as well as user-to-server, server-to-server, and refresh tokens for GitHub Apps. GitHub recommends updating existing tokens as soon as possible to improve security and allow secret scanning to detect the tokens. For more information, see "About authentication to GitHub" and "About secret scanning."

    • You can now authenticate SSH connections to GitHub AE using a FIDO2 security key by adding an sk-ecdsa-sha2-nistp256@openssh.com SSH key to your account. SSH security keys store secret key material on a separate hardware device that requires verification, such as a tap, to operate. Storing the key on separate hardware and requiring physical interaction for your SSH key offers additional security. Since the key is stored on hardware and is non-extractable, the key can't be read or stolen by software running on the computer. The physical interaction prevents unauthorized use of the key since the security key will not operate until you physically interact with it. For more information, see "Generating a new SSH key and adding it to the ssh-agent."

    • Git Credential Manager (GCM) Core versions 2.0.452 and later now provide secure credential storage and multi-factor authentication support for GitHub AE. GCM Core with support for GitHub AE is included with Git for Windows versions 2.32 and later. GCM Core is not included with Git for macOS or Linux, but can be installed separately. For more information, see the latest release and installation instructions in the microsoft/Git-Credential-Manager-Core repository.

  • Notifications

    • You can now configure which events you would like to be notified about on GitHub AE. From any repository, select the Watch drop-down, then click Custom. For more information, see "Configuring notifications."

  • Issues and pull requests

    • With the latest version of Octicons, the states of issues and pull requests are now more visually distinct so you can scan status more easily. For more information, see the GitHub Blog.

    • You can now see all pull request review comments in the Files tab for a pull request by selecting the Conversations drop-down. You can also require that all pull request review comments are resolved before anyone merges the pull request. For more information, see "About pull request reviews" and "About protected branches." For more information about management of branch protection settings with the API, see "Branches" in the REST API documentation and "Mutations" in the GraphQL API documentation.

    • You can now upload video files everywhere you write Markdown on GitHub AE. Share demos, show reproduction steps, and more in issue and pull request comments, as well as in Markdown files within repositories, such as READMEs. For more information, see "Attaching files."

    • GitHub AE now shows a confirmation dialog when you request a review from a team with more than 100 members, allowing you to prevent unnecessary notifications for large teams.

    • When an issue or pull request has fewer than 30 possible assignees, the assignees control will list all potential users rather than a limited set of suggestions. This behavior helps people in small organizations to quickly find the right user. For more information about assigning users to issues and pull requests, see "Assigning issues and pull requests to other GitHub users."

    • You can now include multiple words after the # in a comment for an issue or pull request to further narrow your search. To dismiss the suggestions, press Esc.

    • To prevent the merge of unexpected changes after you enable auto-merge for a pull request, auto-merge is now disabled automatically when new changes are pushed by a user without write access to the repository. Users without write access can still update the pull request with changes from the base branch when auto-merge is enabled. To prevent a malicious user from using a merge conflict to introduce unexpected changes to the pull request, GitHub AE will disable auto-merge for the pull request if the update causes a merge conflict. For more information about auto-merge, see "Automatically merging a pull request."

    • People with maintain access can now manage the repository-level "Allow auto-merge" setting. This setting, which is off by default, controls whether auto-merge is available on pull requests in the repository. Previously, only people with admin access could manage this setting. Additionally, this setting can now by controlled using the "Create a repository" and "Update a repository" REST APIs. For more information, see "Managing auto-merge for pull requests in your repository."

    • The assignees selection for issues and pull requests now supports type ahead searching so you can find users in your organization faster. Additionally, search result rankings have been updated to prefer matches at the start of a person's username or profile name.

  • Repositories

    • When viewing the commit history for a file, you can now click to view the file at the specified time in the repository's history.

    • You can now use the web UI to synchronize an out-of-date branch for a fork with the fork's upstream branch. If there are no merge conflicts between the branches, GitHub AE updates your branch either by fast-forwarding or by merging from upstream. If there are conflicts, GitHub AE will prompt you to open pull request to resolve the conflicts. For more information, see "Syncing a fork."

    • You can now sort the repositories on a user or organization profile by star count.

    • The Repositories REST API's "compare two commits" endpoint, which returns a list of commits reachable from one commit or branch, but unreachable from another, now supports pagination. The API can also now return the results for comparisons over 250 commits. For more information, see the "Commits" REST API documentation and "Traversing with pagination."

    • When you define a submodule in your enterprise with a relative path, the submodule is now clickable in the web UI. Clicking the submodule in the web UI will take you to the linked repository. Previously, only submodules with absolute URLs were clickable. Relative paths for repositories with the same owner that follow the pattern ../REPOSITORY or relative paths for repositories with a different owner that follow the pattern ../OWNER/REPOSITORY are supported. For more information about working with submodules, see Working with submodules on the GitHub Blog.

    • By precomputing checksums, the amount of time a repository is under lock has reduced dramatically, allowing more write operations to succeed immediately and improving monorepo performance.

  • Releases

    • You can now react with emoji to all releases on GitHub AE. For more information, see "About releases."

  • Themes

    • Dark and dark dimmed themes are now available for the web UI. GitHub AE will match your system preferences when you haven't set theme preferences in GitHub AE. You can also customize the themes that are active during day and night. For more information, see "Managing your theme settings."

  • Markdown

    • Markdown files in your repositories now automatically generate a table of contents in the header the file has two or more headings. The table of contents is interactive and links to the corresponding section. All six Markdown heading levels are supported. For more information, see "About READMEs."

    • code markup is now supported in titles for issues and pull requests. Text within backticks (`) will appear rendered in a fixed-width font anywhere the issue or pull request title appears in the web UI for GitHub AE.

    • While editing Markdown in files, issues, pull requests, or comments, you can now use a keyboard shortcut to insert a code block. The keyboard shortcut is command + E on a Mac or Ctrl + E on other devices. For more information, see "Basic writing and formatting syntax."

    • You can append ?plain=1 to the URL for any Markdown file to display the file without rendering and with line numbers. You can use the plain view to link other users to specific lines. For example, appending ?plain=1#L52 will highlight line 52 of a plain text Markdown file. For more information, "Creating a permanent link to a code snippet."

  • GitHub Apps

    • API requests to create an installation access token now respect IP allow lists for an enterprise or organization. Any API requests made with an installation access token for a GitHub App installed on your organization already respect IP allow lists. This feature does not currently consider any Azure network security group (NSG) rules that GitHub Support has configured for your enterprise. For more information, see "Restricting network traffic to your enterprise," "Managing allowed IP addresses for your organization," and "Apps" in the REST API documentation.

  • Webhooks

    • You can now programmatically resend or check the status of webhooks through the REST API. For more information, see "Repositories," "Organizations," and "Apps" in the REST API documentation.

GitHub AE 3.1

GitHub a commencé à déployer ces changements pour les entreprises le March 03, 2021.

3.1.0: Features

  • GitHub Actions beta

    • GitHub Actions is a powerful, flexible solution for CI/CD and workflow automation. For more information, see "Comprendre GitHub Actions."

      Please note that when GitHub Actions is enabled during this upgrade, two organizations named "GitHub Actions" (@actions and @github) will appear in your enterprise. These organizations are required by GitHub Actions. Users named @ghost and @actions appear as the actors for creation of these organizations in the audit log.

  • GitHub Packages beta

    • GitHub Packages is a package hosting service, natively integrated with GitHub Actions, APIs, and webhooks. Create an end-to-end DevOps workflow that includes your code, continuous integration, and deployment solutions. During this beta, GitHub Packages is offered free of charge to GitHub AE customers.

  • GitHub Advanced Security beta

    • GitHub Advanced Security is available in beta and includes both code scanning and secret scanning. During this beta, GitHub Advanced Security features are being offered free of charge to GitHub AE customers. Repository and organization administrators can opt-in to use GitHub Advanced Security in the Security and Analysis tab under settings.

      Learn more about GitHub Advanced Security code scanning and secret scanning on GitHub AE.

  • Manage teams from your identity provider (IdP)

    • Customers using SCIM (System for Cross-domain Identity Management) can now sync security groups in Azure Active Directory with GitHub teams. Once a team has been linked to a security group, membership will be automatically updated in GitHub AE when a user is added or removed from their assigned security group.

  • IP allow lists beta

    • GitHub IP allow lists provide the ability to filter traffic from administrator-specified IP ranges, defined by CIDR notation. The allow list is defined at the enterprise or organization account level in Security > Settings. All traffic that attempts to reach resources within the enterprise account and organizations are filtered by the IP allow lists. This functionality is provided in addition to the ability to request network security group changes that filter traffic to the entirety of the GHAE tenant.

3.1.0: Changes

  • Developer Changes

    • Organization owners can now disable publication of GitHub Pages sites from repositories in the organization. This will not unpublish existing sites.

    • Repositories that use GitHub Pages can now build and deploy from any branch.

    • When writing an issue or pull request, the list syntax for bullets, numbers, and tasks will now be autocompleted after you press return or enter.

    • You can now delete a directory in a repository from the repository page. When navigating to a directory, a new kebab button next to the "Add file" button gives the option to delete the directory.

    • It's now easier and faster to reference issues or pull requests, with search across multiple words after the "#".

  • Administration changes

    • Enterprise owners can now publish a mandatory message. The message is shown to all users and they must acknowledge it. This can be used to display important information, terms of service or policies.

    • The GitHub App single file path permission can now support up to ten files.

    • When configuring a GitHub App, the authorization callback URL is a required field. Now we will permit the integrator to specify multiple callback URLs. GitHub AE denies authorization if the callback URL from the request is not listed.

    • A new API endpoint enables the exchange of a user to server token for a user to server token scoped to specific repositories.

    • Events are now logged in the audit log on promoting a team member to be a team maintainer and on demoting a team maintainer to be a team member.

    • The OAuth device authorization flow is now supported. This allows any CLI client or developer tool to authenticate using a secondary system.

    • A user can no longer delete their account if SCIM provisioning is enabled.

  • Default branch renaming

    • Enterprise and organization owners can now set the default branch name for new repositories. Enterprise owners can also enforce their choice of default branch name across all organizations or allow individual organizations to choose their own.

      Existing repositories are unaffected by these settings, and their default branch name will not be changed.

      This change is one of many changes GitHub is making to support projects and maintainers that want to rename their default branch. To learn more, see github/renaming.

3.1.0: Bug fixes

  • Bug fixes

    • Users can no longer set a backup email address on their profile. Their email address is set through the IdP only.

    • You can no longer enable two-factor authentication after configuring authentication through your IdP.

    • GitHub AE can now connect to Azure Boards.

    • Version headers were missing from the APIs, and have now been set to "GitHub AE."

    • Links to documentation have been fixed.

    • Configuration of audit log forwarding within the enterprise's settings was failing.

    • Navigating to gists could result in a 500 error.

    • The Support email or URL was failing to save. It now saves after a period of a few minutes.

    • Organization level pull request templates were not being applied to all pull requests in the organization.

3.1.0: Known issues

  • Known issues

    • Geographic location data is not shown in the audit log. Location information can otherwise be discerned from the IP address associated with each event.

    • The link to GitHub Packages from a repository page shows an incorrect search page when that repository does not have any packages.