| Jun | JUL | Aug |
| 01 | ||
| 2017 | 2018 | 2019 |
COLLECTED BY
Collection: General Crawls
GraphQL API v4
REST API v3
Apps
Webhooks
Blog
Forum
GitHub.com
Enterprise 2.13
Enterprise 2.12
Enterprise 2.11
jakeboxer
We're adding some API parameters to support the new project card archiving feature.
true for the archived parameter. To restore an archived card, use the same API endpoint, passing false for the archived parameter.
"archived" for the archived_state parameter, you will see that column's archived cards instead. If you pass "all" for the archived_state parameter, you will see every card in the column, whether or not it is archived.
Accept header:
application/vnd.github.inertia-preview+json
tarebyte
●
wilhelmklopp
We've released new endpoints to help you find installations of your app for a given organization, repository, or user.
When authenticated as a GitHub App, you can now use the following endpoints:
●Find organization installation
●Find repository installation
●Find user installation
Accept header:
application/vnd.github.machine-man-preview+json
d12
●
bswinnerton
The node_id attribute, used to identify objects in our GraphQL API from our REST API, has just graduated from preview for GitHub dotcom and GitHub Enterprise versions 2.14 and higher. The node_id attribute will be included in all supported REST resources that have a corresponding GraphQL object, and you can use this information to help move between the REST API and the GraphQL API. For more information, see "Migrating from REST to GraphQL" and "Using global node IDs."
application/vnd.github.v3+json
application/vnd.github.jean-grey-preview+json
benbalter
Starting today, both users and organizations now have the ability to request an archive of their repositories, issues, comments, and other data using the Migrations API.
To access this new API during the preview period, you must provide a custom media type in the Accept header:
application/vnd.github.wyandotte-preview+json
POST request to the /user/migrations endpoint, listing the repositories you'd like to include in the archive:
curl -X POST -H "Accept: application/vnd.github.wyandotte-preview+json" -u USERNAME:TOKEN --data '{"repositories":["USERNAME/REPO", "USERNAME/ANOTHER_REPO"]}' https://api.github.com/user/migrations
GET request to the /user/migrations/:migration_id endpoint, using the migration ID provided in the response to your initial request (or as retrieved from GET /user/migrations):
curl -X GET -H "Accept: application/vnd.github.wyandotte-preview+json" -u USERNAME:TOKEN https://api.github.com/user/migrations/:migration_id
exported state, you can request the URL to your migration archive by making a GET request to the /user/migrations/:migration_id/archive endpoint. This endpoint will return an authenticated URL which you can use to retrieve your archive as a tar.gz file:
curl -X GET -H "Accept: application/vnd.github.wyandotte-preview+json" -u USERNAME:TOKEN https://api.github.com/user/migrations/:migration_id/archive
DELETE request to the /user/migrations/:migration_id/archive endpoint:
curl -X DELETE -H "Accept: application/vnd.github.wyandotte-preview+json" -u USERNAME:TOKEN https://api.github.com/user/migrations/:migration_id/archive
keavy
Building on the recent Checks API, we're providing further actions that users can request from a check run. This feature enables users to select an action offered by the app. For example, users can push a button in GitHub to request that the app fixes previously found linter errors.
actions to be flexible for the integrator to specify which actions they can offer the user.
For example, a linter type app with the ability to fix any failures found includes a "Fix" option, along with the check run input in the new actions input parameter:
"actions": [{
"label": "Fix",
"description": "Let us fix that for you",
"identifier": "fix_errors"
}]
GitHub sends a webhook event to the app with the details of the user request.
GitHub sends a check_run event with action of "requested_action" to the specific app. The payload includes the reference for the particular action requested by the user:
"requested_action": {
"identifier": "fix_errors"
}
write permission on the contents of the repository if you want it to apply the fixes and commit the changed code to the same branch. In GitHub, these changes might look this:
To learn more about how an app can clone and access a repository for making changes, see "HTTP-based Git access by an installation."
Accept header:
application/vnd.github.antiope-preview+json
chobberoni
The Marketplace API is now part of the official GitHub REST API v3.
If you used the Marketplace API during the preview period, you needed to provide a custom media type in the Accept header:
`application/vnd.github.valkyrie-preview+json`
application/vnd.github.v3+json
LizzHale
As part of the ongoing audit of the availability of REST API endpoints for GitHub Apps, we've enabled another batch of endpoints. For a complete list of endpoints enabled for GitHub Apps, see "Available endpoints".
GET /
Accept header:
application/vnd.github.machine-man-preview+json
Instead of binary pass/fail commit statuses, integrators can now report more fine-grained outcomes, such as a neutral conclusion for more informational analysis or action_required if the integrator site requires the user's attention.
We've added first-class support for common workarounds, like the ability to skip or request checks via commit message, trigger checks with a dedicated check_suite webhook event, and set preferences for when checks are triggered.
checks:write permission a check_suite webhook event with the action requested. When an app receives this event, it should perform its analysis on the code changes.
(二)GitHub displays the apps that have been requested to run checks in the pull request view with a status of queued.
(三)An app creates a check run with a started_at timestamp and a status (typically in_progress) for each analysis check that the app performs.
(四)An app updates the check run and includes information about the output of its analysis.
(五)GitHub displays the output of the check run in the pull request view.
(六)Repeat steps four and five if needed. Apps can send data in stages until their analysis is complete—when it sends a completed_at timestamp and conclusion.
(七)GitHub displays all the check suites and runs data in the pull request view.
POST /repos/:owner/:repo/check-suite-requests
skip-checks: true in the trailers of the commit message.
●Torequest a check suite, when automatic creation is disabled, include request-checks: true in the trailers of the commit message.
Note: the trailer would need to be on the last commit of a push. If you supply both trailers, skip-checks wins.
See skipping and requesting checks for individual commits for more information.
When a user requests to re-run a check, a check_run webhook event is delivered to that app's webhook with an action of rerequested. The app is then expected to create a new check run for the given head_sha.
When a user requests to re-run a check suite, a check_suite webhook event is delivered to that app's webhook with an action of rerequested. The app is then expected to create a new check run for all its runs in that suite.
success, failure, neutral, cancelled, timed_out, or action_required. Check runs are more flexible than commit statuses. You can update the lifecycle state by indicating queued, in_progress, or completed through the status field.
Check runs can be created as simply as a commit status with just a name and conclusion for the given commit. They can also include a variety of output data: textual information, images, and feedback on specific lines of code.
Is this supported in the GraphQL API?
No, but we plan to add support in the near future.
Who can use it?
The Checks API is only available to GitHub Apps through a new granular permission: checks.
Accept header:
application/vnd.github.antiope-preview+json
xuorig
To provide a more seamless experience we prefer to continuously evolve our schemas rather than using API versioning. Continuous evolution allows us to iterate faster and provide our integrators with new schema members more often. We do our best to avoid breaking changes, but sometimes it's necessary to offer an unversioned API.
We strive to provide the most stable APIs to our integrators and to provide transparency about new developments. This is why we recently shipped the brand new Breaking Changes page, which announces future breaking changes to our GraphQL schema.
Internally, our engineers mark certain schema members as deprecated using a Ruby API on top of the graphql-ruby gem. Using the changes metadata provided by our engineers, we automatically compute removal dates and generate this breaking changes page, meaning you'll always get up to date information.
Along with the GraphQL Changelog, we hope this helps you build better and more stable integrations! If you have any questions or feedback, please let us know. Happy building!
gjtorikian
●
rlinehan
GitHub Apps have been the preferred way to integrate with GitHub for nearly a year. The advantages over regular OAuth apps include granular permissions, as well as tighter control over where the Apps are installed. However, GitHub Apps could only integrate with GitHub using REST API calls.
The GraphQL API now supports requests made by GitHub Apps. This means that any queryormutation available in our public schema can be made by users authorized through a GitHub App. GraphQL is a great way to fetch data about a variety of resources in a payload that matches your request precisely. For more information on the advantages of GraphQL over REST, see "Migrating from REST."
Go forth and build amazing things! When you've finished, list your Appinthe GitHub Marketplace for the world to see 😉.
1
2
3
…
23
24