api

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

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

Beginning January 8th, 2024, we will be making changes to the repository insights UI and API on GitHub for repositories with over 10,000 commits. The targeted UI and API have very low usage and rely on a legacy service we’re moving away from.

User Interface Updates

We are removing the following data:

  1. Under Insights > Contributors, we are removing addition/deletion counts for repositories with over 10,000 commits, as well as the dropdown that shows the graphs associated with additions and deletions. All the commit counts and commit count graphs will remain unchanged.
Current page Repos with over 10,000 commits after the change is made
The current Insights > Contributors tab The new tab which shows no dropdown for additions and deletions, and no addition and deletion counts
  1. Under Insights > Code Frequency, we will only show data for repos with under 10k commits.
Current page Repos with over 10,000 commits after the change is made
The current Insights > Code Frequency tab which shows a graph of additions and deletions over time The new tab which shows that there are too many commits to generate this graph

REST API Modifications

Alongside the UI changes, the following API changes will be implemented:

  1. The REST API responses for repositories with 10,000+ commits will report 0 values for the addition and deletion counts to improve performance. This impacts the /repos/{owner}/{repo}/stats/contributors endpoint to get all contributor commit activity
  2. The /repos/{owner}/{repo}/stats/code_frequency API endpoint will return a 422 status code for repos with 10,000 or more commits.
    • This is different from the previous two because this endpoint only returns additions/deletions, which we will no longer return for repos with over 10k commits. The previous two endpoints also return the total number of commits, which we will continue to generate.

For users who continue to need detailed addition and deletion statistics for large-scale repositories, we suggest using the following Git command, as described in the Git documentation:

git log --pretty="format:%m%ad----%ae%n%-(trailers:only,unfold)" --date=raw --shortstat --no-renames --no-merges

See more

Starting today, apps and tokens used to create a release via the REST API endpoint will require the workflow scope or workflows:write permission in certain cases.

The workflow scope or workflows:write will be required when creating a release that targets a commit SHA (target_commitish) that modifies an Actions workflow file and that SHA does not have an existing ref (branch head or tag).

For more details see the REST API documentation or visit the GitHub Actions community if you have any questions.

See more

There are two new metrics available under the Repository object in the GraphQL API:

  • LastContributionDate – The most recent date there was any of the following activity: a commit to a repository’s default branch, opening an issue or discussion, answering a discussion, proposing a pull request, or submitting a pull request review. This is a good single-number metric to find projects that may be unmaintained or in need of archiving.
  • CommitCount – A monotonically increasing count of the total number of commits pushed to the default branch of the repository. Tracking the change in this over time will give a sense of the overall activity in the repository.

These metrics are currently in public beta, so you will need to include a header to your GraphQL requests to opt-in:

GraphQL-Features: ospo_metrics_api

Additional documentation and context around these metrics is available in the github-ospo repo. Please provide your feedback on this discussion thread: https://github.com/orgs/community/discussions/72156

See more

Up until recently, the /rate_limit REST API endpoint was not covered by the API's rate limit. While this allowed API consumers to fetch rate limit information whenever they wanted, it was also a potential vector for abuse.

With that in mind, the /rate_limit endpoint is now covered by rate limits. Requests to the endpoint will not consume the primary rate limit quotas for the authenticated user. However, making a very high number of requests to the endpoint in a short period of time will trigger the secondary rate limits. Please follow the guidelines on avoiding the limits and what to do if you do hit them.

These limits are not intended to cause friction for any normal usage of the API. Rather, their aim is to prevent abusive patterns. If you run into any problems with these limits for the /rate_limit endpoint, please contact GitHub Support.

See more

The Source Imports REST API allows integrators to programatically import internet-accessible Git repositories into GitHub.com – for example, from code hosting platforms like Bitbucket Cloud or GitLab.com.

We're ending support for this API due to very low levels of usage and available alternatives. From 00:00 UTC on April 12, 2024, these endpoints will return an error. Integrators affected by this change will receive email alerts ahead of this deprecation.

If you're using the Source Imports API, you'll need to update your integration by that date, or it will stop working. You can learn about alternatives to this API on the new "Programatically importing repositories" page on the GitHub Docs.

See more

Actions customers will now be able to clear stuck workflows by forcing a cancel request from the REST API. This is a new feature and the existing endpoint to cancel a workflow run will remain unchanged.

Sometimes an Actions workflow can become stuck in a state that will not respond to a cancel request. This could block other workflows from executing and would often require customers to contact GitHub Support to resolve the issue. Going forward, customers can invoke force-cancel from the REST API, which will bypass conditions that would otherwise cause the workflow execution to continue. Customers should still only use force-cancel if the workflow fails to respond to POST /repos/{owner}/{repo}/actions/runs/{run_id}/cancel.

For more details see the GitHub Actions workflow runs REST API documentation.

For questions, visit the GitHub Actions community.

To see what's next for Actions, visit our public roadmap.

See more

Public documentation of the SCIM API for Enterprise Managed Users (EMU) is now available.

Administrators of EMU enterprises can use a token with the admin:enterprise scope to make GET requests from SCIM clients. With this read access, you can directly reconcile GitHub's understanding of SCIM-defined users and groups with your federated identity groups for auditing purposes.

Write requests to these APIs are possible through our published IdP applications, or through a new private beta that offers direct API access.

To get write access to these APIs in beta, register your interest here.

See more

A new header will be sent back to API callers that use the fine-grained permission model (GitHub Apps and fine-grained PATs) to help developers discover which permissions are needed to call an API route. This new header, x-accepted-github-permissions, contains the list of permissions required to access the endpoint.

In the fine-grained permission model more than one permission may be needed to access an endpoint. Multiple sets of permissions may also be valid, since there are multiple ways to access data within GitHub. All valid sets are included in the header, each set separated by a semicolon (;).

For example, when calling "List project collaborators", you'll recieve the header x-accepted-github-permissions: repository_projects=write; organization_projects=admin. This indicates that to get the list of collaborators on a project, you need either the repository_projects Write permission or the organization_projects Admin permission.

This header is used in the same way as the x-accepted-oauth-scopes header for coarse-grained scope actors (OAuth apps and PATs (Classic)).

To learn more about troubleshooting permissions issues with GitHub Apps and fine-grained PATs and to get more information about this header, see "Insufficient permission errors". To see the permissions needed for each endpoint, see "Permissions required for GitHub Apps" and "Permissions required for fine-grained PATs".

See more

For security reasons, source IP addresses have been removed from error messages that are returned from the GitHub API when callers try to access protected resources from non-permitted IP addresses.

To learn more about IP allow lists, visit Restricting network traffic to your enterprise with an IP allow list in the GitHub documentation.

If you'd like to learn more about your source IP addresses, please contact GitHub Support.

See more

Enterprise users will now notice added functionality where Dependabot security and version updates may be paused for repositories.

If you are an enterprise user that uses Dependabot updates and there has been no activity in a repository, such as merging, closing, or any other interaction, with Dependabot pull requests for a period exceeding 90 days, the updates will be paused. To resume activity, simply merge or close one of Dependabot's pull requests, or modify the Dependabot config file in the repository.

This change will help Dependabot be more focused to the repositories you care about and reduce use of GitHub Actions minutes on inactive Dependabot pull requests.

If you are using security overview with GitHub Advanced Security, you will be able to see which repositories in your organization have been paused from the security coverage view.

You will also be able to see whether Dependabot has been paused for a repository by querying the /repos/{owner}/{repo}/automated-security-fixes REST API endpoint, which will return both the enablement status and paused status of the repository.

When will Dependabot become paused?

This change only applies to repositories where Dependabot pull requests exist but remain untouched. If no Dependabot pull requests have been opened, Dependabot will never become paused.

The following must be true for at least 90 days:

  • Has not had a Dependabot PR merged
  • Has not had changes made to the Dependabot config file
  • Has not had any @dependabot comment-ops performed
  • Has not had any Dependabot PRs closed by the user
  • Has received at least one Dependabot PR before the 90 day window
  • Has at least one Dependabot PR open at the end of the 90 day window
  • Has had Dependabot enabled for this entire period

How will Dependabot let me know?

Dependabot will add a notice to the body of all open Dependabot pull requests and add a dependabot-paused label to them. Dependabot will also add a banner notice in the UI of your repository settings page (under “Dependabot”) as well as your Dependabot alerts page (if Dependabot security updates are affected).

Who can use this feature?

This change does not apply to Dependabot alerts or subsequent notifications. So, only repositories that have automated Dependabot version updates or security updates, but haven't interacted with these pull requests for a while, will be affected.

Learn more about this change
Learn more about how to interact with the REST API

See more

Today's Changelog brings you board column limits, an improved item menu to move your board items and updates to Issue hierarchy powered by tasklists!

🔢 Board column limits

You can now set column limits on the board layout to help you limit your work in progress as well as promote focus on the items that really matter. Column limits are based off of the number of items in a column, and are unique to each board view.

To configure a limit, set the value from the column's ... menu. If you exceed the limit, the value will be highlighted in red.

As always, we'd love to hear from you! Let us know your feedback in our community discussion.

Updated menu to move board items

Following our support for bulk updates and keyboard shortcuts, we've made it even easier to move the items on your boards. Select the item ... menu to move an item to the top or bottom of a column, or to a different column altogether.

➕ Add tasklist button

a picture of the same issue in projects and in issues which shows the new add tasklist button on the bottom left of the issue description

You may have noticed a new button has appeared on issues and the projects side-panel! You can now easily add tasklists to your issues without ever having to enter your issue's Markdown.

📁 Drag and drop improvements in table layout

Items can be dragged into collapsed groups in the table layout. Items can also be dragged and dropped across groups when sorting is enabled.

🏗️ Export project view as a CSV file

You can now download a view by selecting the view menu and clicking Download CSV.

Screenshot 2023-06-15 at 2 42 26 PM

👀 Upcoming change to insights

Historical charts will no longer support group by values. We will be phasing historical charts out over the next couple of months and no new accounts will be added to the existing support.

Bug fixes and improvements

  • Fixed a permissions bug when reordering fields within a group
  • Single select edit option modal updates preview label text
  • Updated icon color of Make a copy icon
  • Fixed visual bug on Delete project and Issue transfer modals
  • Can now delete a project if there is an emoji in the name
  • Issue title created using the Add item bar now populates in the issue create modal
  • Added keyboard shortcuts for metadata edits (improvements to this coming soon!)
  • Tasklists now throw an error (instead of silently failing) when formatting is incorrect
  • Fixed a bug where tasklist name changes were not being persisted
  • Fixed a regression where tasklists did not show the preview title when adding issues
  • Fixed a regression in the tasklist omnibar which broke the autocomplete functionality
  • Fixed a bug preventing users from selecting multiple rows in the table
  • Fixed a bug where users couldn't copy assignees table cells

See how to use GitHub for project planning with GitHub Issues, check out what's on the roadmap, and learn more in the docs.

See more

The "Remove a repository from an app installation" API has been updated to fail early if attempting to remove a repository from an application that is installed on all repositories.

To switch an application InstallationState from the all to some state in your organization, an organization owner or application manager must make this change within the UI, while picking up to 50 repositories for the app to continue to have access to. From there, additional repositories can be added via the UI or the "Add a repository to an app installation" API.

To learn more about managing application installations, see "Modifying repository access". For details on the GitHub App REST API, see "GitHub Apps".

See more