Focused crawls are collections of frequently-updated webcrawl data from narrow (as opposed to broad or wide) web crawls, often focused on a single domain or subdomain.
Focused crawls are collections of frequently-updated webcrawl data from narrow (as opposed to broad or wide) web crawls, often focused on a single domain or subdomain.
TIMESTAMPS
The Wayback Machine - https://web.archive.org/web/20250401110207/https://github.blog/changelog/
Moving forward, we recommend using GitHub Enterprise Importer (GEI) to migrate repositories to GitHub’s cloud-based products. If you are interested in migrating GitLab repositories to GitHub using GEI, please contact our Expert Services team.
The cvss field for GitHub security advisories in the REST and GraphQL APIs will be deprecated in favor of the new cvss_severities field. cvss will be removed from the REST API on April 1, 2025, and removed from the GraphQL API on October 1, 2025.
Starting on April 28th, 2025, GitHub will implement a new limit of 100,000 repositories on the total number of repositories per owner for both user accounts and organizations.
We’re committed to keeping our platform safe and secure while delivering the experiences you expect. By capping repository ownership, we’re preventing slowdowns on administrators as well as ensuring the health of our infrastructure to provide a smooth and secure environment for all users. You can find more about the degraded performance large accounts can face exceeding 100,000 repositories in our documentation about repository limits.
Notification process
When an account surpasses 50,000 repositories, a banner noting the approaching limit will appear. Additionally, administrators will receive email notifications, and the audit log will update every additional 5,000 repositories created.
Temporary exemptions
For accounts at or nearing the 100,000-repository limit, GitHub will provide information on temporary exemptions and offer guidance on reducing repository counts. If you require more than 100,000 repositories, you can distribute ownership across multiple organizations, maintaining seamless operations.
Additional resources
The stale repos action that was launched in 2023 is designed to help organizations identify and report on repositories with no activity.
For further details and guidance on navigating these changes, please visit our documentation.
The GPT-4o Copilot model released in preview last month and updated this month now provides code completions for all Copilot users. This model delivers higher quality suggestions and improved latency.
Getting ready
No additional action is required if you’re on the latest version of the GitHub Copilot extension for VS Code, Visual Studio, or JetBrains. If you’re on an older version of the GitHub Copilot extension, the model will roll out to you in the coming days. Updating your extension will ensure quicker access.
Retirement of GPT-3.5 Turbo based model
Over the coming days, your code completion experience will switch to GPT-4o Copilot. The GPT-3.5 Turbo based copilot-codex model, which was the previous model, will no longer be available.
Your feedback
Thank you to the tens of thousands of developers who used this new model in preview. Please continue to share your feedback directly and in the GitHub Community!
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
Dependabot alerts now contain a direct label if they are associated with a package you’ve directly included. In addition, there’s now a relationship:direct filter in the search bar to only show those alerts caused by your direct dependencies.
The direct dependency that led to a package’s inclusion in your dependency graph is visible both in the text of any new Dependabot alerts and the dependency insights page (click the … button, then Show options to view it).
A repository’s SBOM will contain a relationships section that uses the SPDX relationshipType: DEPENDS_ON field to express the tree of package dependencies. Similarly, the GraphQL API will now return a relationship field with direct, transitive, or unknown values in the DependencyGraphDependency object.
Ability to refresh Dependabot alerts from the list view
In addition to the Maven-specific additions, the Alert Settings menu on Dependabot alert tables now provides a Refresh Dependabot alerts option which will rescan your repository’s manifest files, rebuild its dependency graph, and refresh its open Dependabot alerts.
Getting started
To get transitive dependency labeling on your repositories, make sure dependency graph is enabled, and either enable Automatic dependency submission on the same settings page or use a dependency submission action. As a beneficial side-effect of this change, other package ecosystems with actions that create transitive dependency trees – such as go – will also now receive transitive and direct labels.
Enterprise custom properties and enterprise rulesets are now generally available, further improving the governance features for GitHub Enterprise customers.
Enterprise custom properties
With enterprise-level custom properties, you can now enrich your repositories with metadata across your entire enterprise. This ensures consistent properties across organizations without the need for manual synchronization. By sharing a common namespace, enterprise and organization properties prevent confusion when searching or targeting rulesets with properties. If you’re already using custom properties in your organizations, you can also promote those properties to the enterprise.
Enterprise-level rulesets enforce consistent code governance rules, helping ensure thorough reviews of critical repositories with pull requests, requiring actions workflows, protecting important locations from unauthorized pushes, and more. Rule insights and push rule bypasses are also available at the enterprise level, providing complete visibility into the rulesets.
We look forward to seeing how you leverage these new capabilities to streamline your workflows and maintain high standards of code governance.
Pull request merge method rule
The new pull request merge method rule is now generally available using whatever method is suitable for your branches, such as ensuring that all changes are squashed when merging to the default branch while rebasing into feature branches. This simplifies your workflows, ensuring consistency across your branches.
The merge method rule is available for rulesets at the repository and organization level. You can use this rule to choose what merge methods are allowed on the targeted branches when merging pull requests from the user interface or APIs. You can choose between merge commit, squash, or rebase.
We’ve made it easier to break down and manage your work on the go! You can now create, add, and remove sub-issues seamlessly on GitHub Mobile, keeping everything organized and structured. Stay on top of your tasks with improved sub-issue management, ensuring smoother collaboration and better progress tracking.
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
Copilot Edits support is now released in JetBrains IDEs! This update allows you to quickly refactor, optimize, and iterate more efficiently across multiple files.
What’s new ✨
Use Copilot Edits to smoothly make changes in one or multiple files directly from Copilot Chat. To use Copilot Edits, click the Copilot Chat icon in the JetBrains IDE and start a new Edit session.
Benefits for developers ⚡️
Enhanced clarity: Obtain a clear overview of the modifications with a summary of the affected files and the proposed changes.
Ability to preview changes: View code diffs directly in your editor and decide whether to accept or discard these changes individually or collectively.
Boosted productivity: Save time and effort with the help of Copilot Edits, enabling you to focus on more complex tasks.
GitHub has migrated customers to a new cache service and will now be shutting down the old service. This process will include brownouts of the old service before turning it off completely on April 15th, 2025. If your Actions workflows are still hitting the old cache service, your workflows may fail during these brownouts.
The brownout dates and times are as follows:
April 1, 2025, 3 p.m. – 7 p.m. UTC
April 8, 2025, 2 p.m. – 10 p.m. UTC
You may still be using the old service if you’re interacting with the cache in one of the following ways:
Have manually changed (edited or removed) any of the environment variables below:
ACTIONS_CACHE_URL
ACTIONS_RESULTS_URL
ACTIONS_RUNTIME_TOKEN
ACTIONS_CACHE_SERVICE_V2
Modification to deployment permissions
GitHub is modifying how deployment permissions operate. Those with the deployment: read fine-grain permission can currently review, approve, or reject deployments.
As of April 1, 2025, GitHub will require the deployments: write permission to review, approve, or reject a deployment. Please update any impacted fine-grain PATs to provide write access where needed. Impacted customers were contacted via email in early March 2025.
Failure to update your fine-grained PATs by April 1, 2025 will result in the inability to review, approve, or reject deployments.
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
Mistral Small 3.1 (25.03) is now available in GitHub Models.
Mistral Small 3.1 (25.03) is a versatile AI model designed to assist with programming, mathematical reasoning, dialogue, and in-depth document comprehension. Equipped with multimodal capabilities, it processes both text and visual inputs, making it suitable for chat-based interactions and instruction-following tasks.
Issue types can now be managed using the REST API, expanding the ability to automate and incorporate them in your workflows. Check out our documentation on issue types for more details. You can also review the examples below to get started.
Managing issue types for the organization
You can create, update, delete, and list issue types for an organization.
Creating a new issue type:
curl --request POST \
--url https://api.github.com/orgs/{org}/issue-types \
--header 'authorization: token <YOUR-TOKEN>' \
--header 'content-type: application/json' \
--data '{
"name": "Initiative",
"description": "A large body of work that spans a quarter.",
"color": "orange",
"is_enabled": true
}'
Adding an issue type to an issue
You can specify the issue type when creating a new issue, or update it on an existing issue.
Creating a new issue:
curl --request POST \
--url https://api.github.com/repos/{org}/{repo}/issues \
--header 'authorization: ' \
--header 'content-type: application/json' \
--data '{
"title": "Error when refreshing the settings page",
"type": "Bug"
}'
However, feedback has been clear on one item in particular – while fine-grained PATs solve a significant set of challenges in their current state, many organizations cannot fully adopt them due to the lack of support statements and the risk of breaking changes while they’re in public preview. Our goal at GitHub is to ensure that everyone can secure their workflows as best they can, which is why we’re graduating fine-grained PATs to a generally available (GA) state.
Changes with this release
This update brings two major changes to PATs at GitHub. Most notably, fine-grained PATs are now enabled by default for all organizations on GitHub, unless that organization or enterprise explicitly disabled them during the preview. The PAT approval flow is also enabled by default, so developers must request organization owner approval in order to successfully use their fine-grained PAT against their organizations.
We’re also updating the release state for both fine-grained PATs and PAT expiration policies. These features are now fully supported by GitHub and adhere to the same breaking change policies as the rest of the product. While there are some scenarios where fine-grained PATs are not yet supported, your organization should be confident in suggesting, or even requiring, the use of these more secure tokens.
Administrators, auditors, and security teams can also look for improved auditability of PATs – the token_id is now included in all API calls and supported as a built-in filter in the audit logs. With this filter, you can now easily track the use of a token throughout your enterprise or organization.
Customers on GHES should expect these changes to arrive in version 3.17.
Feature gaps in fine-grained PATs
There are several scenarios where fine-grained PATs are not a suitable solution at this time. GitHub continues to invest in building more secure access patterns and will implement these capabilities over time. You can track our progress and goals on our public roadmap. The most notable scenarios are:
Calling APIs that manage the Enterprise object (e.g. SCIM APIs or creating organizations)
Accessing multiple organizations with a single token
Contributing to repositories where you’re an outside collaborator or an unaffiliated open source contributor
Accessing internal repositories in your enterprise, outside of a targeted organization
Calling the Packages and Checks APIs
We’re currently focused on implementing enterprise access for GitHub Apps and fine-grained PATs so that enterprise owners can reduce the over-permissioning of their current automation solutions. After that, we’ll continue to invest in this area with a goal of enabling organizations to eventually disable the use of PATs (Classic) for their resources.
Starting March 29, 2025, fine-grained Personal Access Tokens (PATs) and GitHub Apps accessing the GitHub Models playground will require the models:read permission. If your tokens or GitHub Apps currently do not include the models:read permission, requests to the playground will return an Unauthorized response after this date. Please update your fine-grained PATs and GitHub Apps permissions proactively to avoid disruption.
Coarse-grained tokens are unaffected and will continue working without any changes.
Developers using upload-artifact and download-artifact in their Actions workflows can now ensure the integrity of their artifacts with the new SHA256 digest. This feature automatically verifies that the artifact uploaded is identical to the one downloaded, providing security for Actions runs and ensuring the artifact remains unchanged.
How it works
Whenever upload-artifact is used, it now computes and stores an output called digest. This is the SHA256 digest of the artifact uploaded during the run.
When download-artifact is used to download that same artifact, it uses the same process to compute a digest for the downloaded file and compares the two digests to validate that they match.
If a mismatch is detected, the run displays a warning in the UI and in the job logs. The workflow won’t fail if the digests don’t match, but this may change in a future release.
Note: This functionality is only available with artifacts v4 or newer. It’s also not currently available on GitHub Enterprise Server.
Where can I view the digest?
The digest will appear in the logs of the workflow run under the “upload-artifact” step. They’ll also appear in the Artifact output that appears in the workflow run UI.
Inspired by our previous release, working with Copilot Chat on GitHub has become even more seamless. You can instantly preview HTML files, edit files you’ve created, and work on issues right away. Several exciting new capabilities give you more control and flexibility.
What’s new
Preview your rendered HTML files directly in the side panel
Edit files in the side panel to seamlessly refine and adjust them
Generate and preview Mermaid diagrams for fast visualizations, whether they’re flowcharts or sequence diagrams
Keep tabs on your issues in the same right side panel, ensuring you can tackle open tasks while discussing them
Track issues or pull requests in responses that are rendered in a familiar GitHub style, making working with them easier
In addition, you can enjoy a smoother streaming experience and enhanced rendering of attachments.
Try it out
See the updated experience in action by submitting any of the following example prompts:
Join us as we continue to streamline Copilot Chat, giving you instant previews, flexible editing, and more power right where you need it! Your feedback drives our improvements. Let us know how these new changes enhance your workflow by using the in-product feedback option or sharing your thoughts in the GitHub Community.
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
GitHub’s Payment Card Industry Data Security Standard (PCI DSS) v4.0 service provider Attestation of Compliance (AoC) as well as the corresponding shared responsibility matrix has been completed. This report is the first time GitHub has provided a PCI DSS service provider report for our customers. This enables customers to meet their own PCI DSS compliance needs using GitHub as part of their development environment.
Going forward, GitHub intends to provide this attestation of compliance each year.
If you’re an Enterprise customer and need to obtain copies of GitHub’s AoC or Shared Responsibility Matrix, please reach out to your account manager.
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
Performance Metrics for GitHub Actions are now generally available for repositories and organizations. Repository members can view workflow and job performance data including queue times and failure rates going back as far as one year. Organization members can also view this data aggregated across all repositories in their organization. These metrics are available on all GitHub Cloud plans.
In addition, usage and performance metrics aggregated at the Enterprise level are now available in public preview to Enterprise admins. This includes usage metrics (ex. jobs run and minutes used), as well as performance metrics (ex. job failure rates and queue times) across all repositories and organizations in an enterprise. These metrics can be found in the Enterprise UI under the “Insights” tab.
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
Developers can now use Dependabot to automatically keep their uv dependencies up to date. For projects that use uv as a package manager, Dependabot version updates can now ensure dependencies stay current with the latest releases.
GitHub Copilot now features instant semantic code search indexing, dramatically reducing the time it takes for Copilot to understand and reference your codebase.
What’s changed
Previously, when you wanted GitHub Copilot to reference your repository’s code in its responses, the semantic code search indexing process would take approximately five minutes to complete. With this update, indexing now completes in just a few seconds in most cases, though it may take up to 60 seconds. This means you can get contextually-aware Copilot assistance almost immediately after opening a repository.
Provide responses specific to your codebase’s architecture and patterns.
Reference existing functions, classes, and implementations in your repo.
Suggest code that aligns with your project’s style and conventions.
Answer questions about your codebase with accurate, context-aware information.
With instant semantic code search indexing, there’s virtually no waiting period between opening a repository and receiving codebase-aware AI assistance, making your development workflow more efficient and interruption-free.
How it works
Semantic code search indexing is automatically triggered when you open GitHub Copilot Chat on github.com. For VS Code users with the GitHub Copilot extension, you can also manually trigger indexing through the Copilot UI if needed.
Availability
This feature is available to all GitHub Copilot users across all tiers, including the free tier. There are no limits on how many repositories can be indexed.
Learn more
For detailed information about repository indexing for GitHub Copilot, check out our documentation.
