bswinnerton
| May | JUN | Jul |
| 04 | ||
| 2017 | 2018 | 2019 |
COLLECTED BY
Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
History is littered with hundreds of conflicts over the future of a community, group, location or business that were "resolved" when one of the parties stepped ahead and destroyed what was there. With the original point of contention destroyed, the debates would fall to the wayside. Archive Team believes that by duplicated condemned data, the conversation and debate can continue, as well as the richness and insight gained by keeping the materials. Our projects have ranged in size from a single volunteer downloading the data to a small-but-critical site, to over 100 volunteers stepping forward to acquire terabytes of user-created data to save for future generations.
The main site for Archive Team is at archiveteam.org and contains up to the date information on various projects, manifestos, plans and walkthroughs.
This collection contains the output of many Archive Team projects, both ongoing and completed. Thanks to the generous providing of disk space by the Internet Archive, multi-terabyte datasets can be made available, as well as in use by the Wayback Machine, providing a path back to lost websites and work.
Our collection has grown to the point of having sub-collections for the type of data we acquire. If you are seeking to browse the contents of these collections, the Wayback Machine is the best first stop. Otherwise, you are free to dig into the stacks to see what you may find.
The Archive Team Panic Downloads are full pulldowns of currently extant websites, meant to serve as emergency backups for needed sites that are in danger of closing, or which will be missed dearly if suddenly lost due to hard drive crashes or server failures.
ArchiveBot is an IRC bot designed to automate the archival of smaller websites (e.g. up to a few hundred thousand URLs). You give it a URL to start at, and it grabs all content under that URL, records it in a WARC, and then uploads that WARC to ArchiveTeam servers for eventual injection into the Internet Archive (or other archive sites).
To use ArchiveBot, drop by #archivebot on EFNet. To interact with ArchiveBot, you issue commands by typing it into the channel. Note you will need channel operator permissions in order to issue archiving jobs. The dashboard shows the sites being downloaded currently.
There is a dashboard running for the archivebot process at http://www.archivebot.com.
ArchiveBot's source code can be found at https://github.com/ArchiveTeam/ArchiveBot.
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."
Now that the preview period has ended (first announced in December 2017), you no longer need to pass this custom media type. Instead, we recommend that you specify v3 as the version in the Accept header:
application/vnd.github.v3+json
Please note that if you use GitHub Enterprise versions 2.11 to 2.13, you will still need to provide a custom media type in the Accept header:
application/vnd.github.jean-grey-preview+json
Onward! Thanks again to everyone that tried out GraphQL global node IDs during the preview period. If you have any questions or feedback, please let us know on the GitHub Platform Forum.
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
During the preview period, we may change aspects of these API methods based on your feedback. If we do, we'll announce the changes here on the developer blog, but we won't provide advance notice.
Before you can download an archive of your data, you must first export it. To start a migration, make a 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
After you've started a migration, you can check the status of your archive by making a 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
Once your migration is in the 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
Your migration archive will remain available to download for seven days. If you would like to delete your archive sooner, you can do so by making a 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
While the migration will continue to exist, the exported archive and its contents will not.
We hope these endpoints can help users to back up or archive their repository data and better understand what information GitHub stores on their behalf.
If you have any questions or feedback, please get in touch with us.
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.
The integrator indicates that they can apply a further action. We designed these 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 surfaces possible actions for that check run in the pull request view.
The user selects the action they want carried out. For example, they click Fix: 
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"
}
The integrator's app carries out that action.
We used a linter app as a use case in the previous examples. This app needs 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."
Anyone can register a GitHub App on GitHub through Settings > Developer settings > GitHub Apps and manage an existing GitHub App from the same place. See how to get started building GitHub Apps.
For more details, refer to the full Checks API documentation.
To access this functionality, you’ll need to provide the following custom media type in the Accept header:
application/vnd.github.antiope-preview+json
We're excited to see what you build with these new improvements. If you have any questions, please let us know.
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`
Now that the preview period has ended, you no longer need to pass this custom media type. Instead, we recommend that you specify v3 as the version in the Accept header:
application/vnd.github.v3+json
You can find the Marketplace API here. If you have any questions or feedback, please get in touch with us.
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".
Check Runs
Check Suites
Repo Hooks
Metadata
Codes of Conduct
Source Imports
Repo Keys
Repos
To access this functionality, you’ll need to provide the following custom media type in the Accept header:
application/vnd.github.machine-man-preview+json
We're actively working on enabling more endpoints. Check back on the developer blog for updates when new batches become available. If you have specific requests or feedback, come chat with us in the Platform forum.
keavy
Today we're adding new functionality which allows integrations and GitHub to communicate more comprehensively about the checks run against code changes. These changes will improve your workflow by allowing you to view feedback from code checks directly in the pull request view, see the line of code causing a problem in the diff view, “re-run” checks, and more-all within the GitHub user interface.
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.queued.started_at timestamp and a status (typically in_progress) for each analysis check that the app performs.completed_at timestamp and conclusion.Because some checks may be expensive to run, an application can opt out of the automatic flow and instead create check suites to their preferred timing. Application owners can control this by setting their check suite preferences on a per-app and repository basis. People with admin permission on a repository can override this setting.
The automatic flow prompts installed apps to run checks against the last commit in code pushed to a repository. A user can request to run checks for any given commit with the request check suites API:
POST /repos/:owner/:repo/check-suite-requests
A user can control the check suite request flow on a per-commit basis:
skip-checks: true in the trailers of the commit message.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.
A user can re-run a check run or entire check suite in the pull request view on GitHub.com.
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.
How do checks work with protected branches?
If the names of check runs are the same as the context of prior commit statuses, and those statuses were required, then the new check runs are automatically required. If a commit status and check run are created with the same name or context, both the status and the check run will be required.
If the names of the new check runs are different from the old commit statuses, the new check runs will need to be selected as required.
How are check runs different than commit statuses?
Commit statuses allow for a simple pass or fail state. Check runs allow for much more granular information: they can conclude as either 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.
Anyone can register a GitHub App on GitHub through Settings > Developer settings > GitHub Apps and manage an existing GitHub App from the same place. See how to get started building GitHub Apps.
See the full Checks API documentation for more details.
To access this functionality, you’ll need to provide the following custom media type in the Accept header:
application/vnd.github.antiope-preview+json
We're excited to see what you build with these new improvements. If you have any questions, please let us know.
Looking for a new app to use? Browse GitHub Marketplace.
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 😉.
gjtorikian
jmilas
GitHub plans on shutting down GitHub Services so we can shift focus to other areas of the API, such as strengthening GitHub Apps and GraphQL, and improving webhooks. The intention of GitHub Services was to allow third-party developers to submit code for integrating with their services, but this functionality has been superseded by GitHub Apps and webhooks. GitHub Services has not supported new features since April 25, 2016, and we plan to officially deprecate it on October 1st, 2018.
As part of the deprecation process, we need integrators on our platform to move from HTTP-based services over to plain webhooks. Webhooks are much easier for both users and GitHub staff to debug on the web because of improved logging.
We have been coordinating with our largest integrators to assist them in seamlessly transitioning from GitHub Services to GitHub Apps and webhooks. In order to move your integration over to plain webhooks, you can leverage either GitHub or OAuth apps. Both "Replacing GitHub Services" and "Differences between GitHub Apps and OAuth Apps" provide information regarding the differences between the two frameworks.
To learn more about this deprecation or moving from GitHub Services to GitHub or OAuth apps, check out "Replacing GitHub Services". Each service will be unique, so we don’t have a single prescriptive process to offer, but we are available as a resource to your team. Please contact our Partner Engineering team with questions.
vroldanbet
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 and identifying and authorizing users for GitHub Apps.
Deployments & Deployment Statuses
Git Blobs & Refs
Issues & Issue Events
Labels
Pull Request Review Events
Repo Collaborators, Commits, and Releases
Root
To access this functionality, you’ll need to provide the following custom media type in the Accept header:
application/vnd.github.machine-man-preview+json
We're actively working on enabling more endpoints. Check back on the developer blog for updates when new batches become available. If you have specific requests or feedback, come chat with us in the Platform forum.