Actions API GA

The Actions API is now generally available and out of Beta! For more information about this API, see the "Actions API."

Thank you to everyone who tried out this API and provided feedback during the beta period.

Temporary GraphQL Explorer downtime

We are temporarily removing access to GraphQL Explorer so we can improve how it works in different browsers.

The downtime is scheduled for:

• March 20, 2020
  • From 15:00 UTC to 17:00 UTC

We apologize for any inconvenience during this time.

Filtering jobs for a workflow run

We are introducing a breaking change to the List jobs for a workflow run endpoint.

The new default behavior will list jobs from the most recent execution of the workflow run. You can specify all with the filter parameter when you want to see all jobs for a particular workflow run, including from old executions of the workflow run.

Please update your code accordingly, and let us know if you have any questions.

Replacing the "Delete reactions" endpoint

We are announcing a new set of "Deleting reactions" endpoints in the Reactions API to replace the existing "Delete reactions" endpoint DELETE /reactions/:reaction_id.

The new endpoints will allow us to scale and support the Reactions API long-term.

Deprecation timeline

The existing "Delete reaction" endpoint deleting a reaction will be disabled a year from now at the earliest on February 1st 2021.

Replacement endpoints

These are the new replacement Reaction API endpoints for deleting reactions:

• Delete a commit comment reaction
  • DELETE /repos/:owner/:repo/comments/:comment_id/reactions/:reaction_id

• Delete an issue reaction
  • DELETE /repos/:owner/:repo/issues/:issue_number/reactions/:reaction_id

• Delete a reaction to a commit comment
  • DELETE /repos/:owner/:repo/issues/comments/:comment_id/reactions/:reaction_id

• Delete a pull request comment reaction
  • DELETE /repos/:owner/:repo/pulls/comments/:comment_id/reactions/:reaction_id

• Delete team discussion reaction
  • DELETE /orgs/:org/teams/:team_slug/discussions/:discussion_number/reactions/:reaction_id

• Delete team discussion comment reaction
  • DELETE /orgs/:org/teams/:team_slug/discussions/:discussion_number/comments/:comment_number/reactions/:reaction_id

Deprecating OAuth Application API

As mentioned in this previous blog post, GitHub no longer supports the OAuth application endpoints and have replaced them with a version that moves the access token to the request body for improved security.

This deprecation has not been applied to GitHub Enterprise offerings yet. Please check the latest Enterprise release notes to learn when this deprecation is initiated and which version of GitHub Enterprise Server will have the OAuth Application API removed.

As an alternative to authorizing your app, you can use the web application flow or the device flow. The device flow doesn't require using the client_secret and can be used by headless apps. For more information, see "Authorizing OAuth Apps."

Deprecation timeline

Brownouts

During a brownout, calls to the old version of OAuth application endpoints will temporarily fail. The goal is to trigger alerts (assuming there are any) on our customers' services to help find unmigrated endpoint calls.

The brownouts are scheduled for:

• March 17, 2021

  • From 07:00 UTC to 10:00 UTC
  • From 16:00 UTC to 19:00 UTC

• April 14, 2021

  • From 07:00 UTC to 10:00 UTC
  • From 16:00 UTC to 19:00 UTC

Removal date

All calls to the old version of the OAuth application endpoints will return a status code of 404 starting on:

• May 5, 2021 at 16:00 UTC

Changes to make

Using calls to OAuth Application API

If you're using the version of the OAuth Application API that includes :access_token in the path like:

curl -u my_client_id:my_client_secret -X POST "https://api.github.com/applications/123/tokens/my_access_token"

Instead, you'll need to call the new version that moves :access_token in the request body:

curl -u my_client_id:my_client_secret -X PATCH "https://api.github.com/applications/123/token -d {"access_token": "my_access_token"}"

See the list of OAuth application endpoints below that you'll need to replace with the new endpoints.

Endpoints affected

The following list of OAuth Application endpoints are deprecated and should be replaced with the new corresponding endpoints.

If you have any questions or feedback, please let us know!

Deprecating OAuth Authorization API

As mentioned in this previous blog post, GitHub has deprecated the OAuth authorization endpoints and recommends that integrators switch to the web application flow to generate access tokens.

Since the OAuth Authorization API requires password authentication, this API will not work once password authentication has been deprecated.

This deprecation has not been applied to GitHub Enterprise offerings, yet. Though, we still recommend GHES customers to make the changes in their applications, if possible. Please check the latest Enterprise release notes to learn when deprecation is initiated and on which GHES version OAuth Authorization API will be removed.

Deprecation timeline

Removal date

All calls to the OAuth authorization endpoints will return a status code of 404 starting on:

• November 13, 2020 at 16:00 UTC

Brownouts

During a brownout, calls to the old version of the OAuth Authorization API will temporarily fail. The goal is to trigger alerts (assuming there are any) on our customers' services to help find unmigrated endpoint calls.

The brownouts are scheduled for:

• September 30, 2020

  • From 07:00 UTC to 10:00 UTC
  • From 16:00 UTC to 19:00 UTC

• October 28, 2020

  • From 07:00 UTC to 10:00 UTC
  • From 16:00 UTC to 19:00 UTC

Changes to make

Calls to OAuth Authorizations API

If you're making OAuth Authorization API calls to manage your OAuth app's authorizations or to create personal access or OAuth tokens like:

curl -u my_username:my_password -X POST "https://api.github.com/authorizations" -d '{"scopes":["public_repo"], "note":"my token", "client_id":"my_client_id", "client_secret":"my_client_secret"}'

Then you must switch to the web application flow to generate access tokens.

Endpoints affected

The following list of OAuth authorization endpoints are deprecated:

• GET /authorizations
• GET /authorizations/:authorization_id
• POST /authorizations
• PUT /authorizations/clients/:client_id
• PUT /authorizations/clients/:client_id/:fingerprint
• PATCH /authorizations/:authorization_id
• DELETE /authorizations/:authorization_id
• GET /applications/grants
• GET /applications/grants/:grant_id
• DELETE /applications/grants/:grant_id

If you have any questions or feedback, please let us know!

Deprecating password authentication

As mentioned in this previous blog post, GitHub no longer supports basic authentication using a username and password. Instead, we recommend using personal access tokens or the web application flow.

This deprecation has not been applied to GitHub Enterprise offerings yet. Please check the latest Enterprise release notes to learn when this deprecation is initiated and which version of GitHub Enterprise Server will have password authentication removed.

Deprecation timeline

Brownouts

During a brownout, password authentication will temporarily fail. The goal is to trigger alerts (assuming there are any) on our customers' services to help find unmigrated endpoint calls.

The brownouts are scheduled for:

• September 30, 2020

  • From 07:00 UTC to 10:00 UTC
  • From 16:00 UTC to 19:00 UTC

• October 28, 2020

  • From 07:00 UTC to 10:00 UTC
  • From 16:00 UTC to 19:00 UTC

Removal

All password authentication will return a status code of 401 starting:

• November 13, 2020 at 16:00 UTC

Changes to make

Using username/password for basic auth

If you're using username and password to make API calls like:

curl -u my_user:my_password https://api.github.com/user/repos

Instead, use a personal access token when testing endpoints or doing local development:

curl -H 'Authorization: token my_access_token' https://api.github.com/user/repos

For OAuth Apps, you should use the web application flow to generate an OAuth token that's also used in the header:

curl -H 'Authorization: token my-oauth-token' https://api.github.com/user/repos

Endpoints affected

All endpoints called using password authentication are affected.

If you have any questions or feedback, please let us know!

Deprecating API authentication through query parameters

As mentioned in this previous blog post, GitHub no longer supports authentication through query parameters. Instead, we recommend users move the authentication in the header.

This deprecation has not been applied to GitHub Enterprise offerings yet. We still recommend GitHub Enterprise customers make changes in their applications if possible. Please check the latest Enterprise release notes to learn when this deprecation is initiated and which version of GitHub Enterprise Server will have authorization through query parameters removed.

Deprecation timeline

Brownouts

During a brownout, authentication using query parameters will temporarily fail. The goal is to trigger alerts (assuming there are any) on our customers' services to help them find unmigrated authentication calls.

The brownouts are scheduled for:

• March 17, 2021

  • From 07:00 UTC to 10:00 UTC
  • From 16:00 UTC to 19:00 UTC

• April 14, 2021

  • From 07:00 UTC to 10:00 UTC
  • From 16:00 UTC to 19:00 UTC

Removal date

All authentication using query parameters will return a status code of 401 like all other auth failures starting on:

• May 5, 2021 at 16:00 UTC

Changes to make

Starting on May 5, 2021, using access_token as a query parameter to access the API (as a user or as a GitHub App) or using client_id/client_secret to make OAuth app unauthenticated calls will be disabled. For examples, see below.

Common uses of access_token as a query param include:

• Direct calls to the GitHub API using personal access tokens
• GitHub Apps that make user-to-server calls on behalf of the user or with Apps using installation tokens to manage repositories.

Using access_token as a query param

If you're currently making an API call similar to

curl "https://api.github.com/user/repos?access_token=my_access_token"

Instead, you should send the token in the header:

curl -H 'Authorization: token my_access_token' https://api.github.com/user/repos

For details on how to generate a token, see "Creating a personal access token."

For details on how to set the token, see these guidelines.

Using client_id/client_secret as a query param

If you're using an OAuth app's client_id and client_secret to make unauthenticated calls with a higher rate limit similar to

curl "https://api.github.com/user/repos?client_id=my_client_id&client_secret=my_secret_id"

Instead, you should use the following format:

curl -u my_client_id:my_client_secret https://api.github.com/user/repos

Endpoints affected

All requests to endpoints that use the above style of authentication are affected.

If you have any questions or feedback, please let us know!

Automatically marking old incomplete check runs as `stale`

If a check run is in an incomplete state for more than 14 days, GitHub will automatically change the check run's conclusion to stale. The new stale state will be denoted with the symbol and behaves similarly to the timed_out and canceled conclusions. When GitHub marks a check run as stale, a check run webhook event is triggered.

This will prevent old incomplete check runs from stopping apps that rely on the completed check suite event to trigger a flow.

Only GitHub can mark check runs as stale. For more information about possible conclusions of a check run, see the conclusion parameter.

This new behavior will go into effect after February 26th, 2020. All incomplete check runs older than 14 days will be marked stale. This feature will roll out slowly over a couple of days.

Actions API

UPDATE (2020-02-19): The Actions API now includes the new List artifacts for a repository endpoint.

UPDATE (2020-02-18): The Actions API for workflow runs will replace check_suite_id with check_suite_url in responses to better adhere to API conventions.

The Actions API enables you to manage GitHub Actions using the REST API. This includes the management of Secrets and Self-hosted runners.

The following endpoints in the Actions API are available for you to use:

• Artifacts
• Secrets
• Self-hosted runners
• Workflows
• Workflow Jobs
• Workflow Runs

During the public beta period, we may change aspects of these APIs based on developer feedback. If we do, we will announce the changes here on the developer blog, but we will not provide any advance notice.

If you have any questions or feedback, please let us know!