| Oct | NOV | Dec |
| 12 | ||
| 2019 | 2020 | 2021 |
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.
Collection: Archive Team: URLs
Apps
GitHub Actions
GitHub Marketplace
Webhooks
Partnerships
REST API v3
GraphQL API v4
Blog
Forum
GitHub.com
GitHub Enterprise Server 2.21
GitHub Enterprise Server 2.20
GitHub Enterprise Server 2.19
GitHub Enterprise Server 2.18
user
public_repo
repo
repo_deployment
repo:status
read:repo_hook
read:org
read:public_key
read:gpg_key
https://api.github.com/graphqlThe endpoint remains constant no matter what operation you perform.
POST. The exception is an introspection query, which is a simple GET to the endpoint. For more information on GraphQL versus REST, see "Migrating from REST to GraphQL."
To query GraphQL using cURL, make a POST request with a JSON payload. The payload must contain a string called query:
curl -H "Authorization: bearer token" -X POST -d " \
{ \
\"query\": \"query { viewer { login }}\" \
} \
" https://api.github.com/graphql
Note: The string value of "query" must escape newline characters or the schema will not parse it correctly. For the POST body, use outer double quotes and escaped inner double quotes.
GET requests, while mutations operate like POST/PATCH/DELETE. The mutation name determines which modification is executed.
For information about rate limiting, see "GraphQL resource limitations."
Queries and mutations share similar forms, with some important differences.
query {
JSON objects to return
}
For a real-world example, see "Example query."
mutation {
mutationName(input: {MutationNameInput!}) {
MutationNamePayload
}
The input object in this example is MutationNameInput, and the payload object is MutationNamePayload.
In the mutations reference, the listed input fields are what you pass as the input object. The listed return fields are what you pass as the payload object.
For a real-world example, see "Example mutation."
variables before the JSON object.
Here's an example query with a single variable:
Run in Explorer
query($number_of_repos:Int!) {
viewer {
name
repositories(last: $number_of_repos) {
nodes {
name
}
}
}
}
variables {
"number_of_repos": 3
}
variables object:
variables {
"number_of_repos": 3
}
Int variable type, but it's possible to define more complex variable types, such as input objects. You can also define multiple variables here.
Pass the variable to the operation as an argument:
query($number_of_repos:Int!){
$ (e.g., $number_of_repos), and the value is the type (e.g., Int). Add a !to indicate whether the type is required. If you've defined multiple variables, include them here as multiple arguments.
Use the variable within the operation:
repositories(last: $number_of_repos) {
variables object and keep the rest of the query the same.
Using variables as arguments lets you dynamically update values in the variables object without changing the query.
octocat/Hello-World repository, finds the 20 most recent closed issues, and returns each issue's title, URL, and first 5 labels:
Run in Explorer
query {
repository(owner:"octocat", name:"Hello-World") {
issues(last:20, states:CLOSED) {
edges {
node {
title
url
labels(first:5) {
edges {
node {
name
}
}
}
}
}
}
}
}
query {
Because we want to read data from the server, not modify it, query is the root operation. (If you don't specify an operation, query is also the default.)
repository(owner:"octocat", name:"Hello-World") {
To begin the query, we want to find a repository object. The schema validation indicates this object requires an owner and a name argument.
issues(last:20, states:CLOSED) {
To account for all issues in the repository, we call the issues object. (Wecould query a single issue on a repository, but that would require us to know the number of the issue we want to return and provide it as an argument.)
Some details about the issues object:
●The docs tell us this object has the type IssueConnection.
●Schema validation indicates this object requires a lastorfirst number of results as an argument, so we provide 20.
●The docs also tell us this object accepts a states argument, which is an IssueState enum that accepts OPENorCLOSED values. To find only closed issues, we give the states key a value of CLOSED.
edges {
We know issues is a connection because it has the IssueConnection type. To retrieve data about individual issues, we have to access the node via edges.
node {
Here we retrieve the node at the end of the edge. The IssueConnection docs indicate the node at the end of the IssueConnection type is an Issue object.
Now that we know we're retrieving an Issue object, we can look at the docs and specify the fields we want to return:
title
url
labels(first:5) {
edges {
node {
name
}
}
}
title, url, and labels fields of the Issue object.
The labels field has the type LabelConnection. As with the issues object, because labels is a connection, we must travel its edges to a connected node: the label object. At the node, we can specify the label object fields we want to return, in this case, name.
You may notice that running this query on the Octocat's public Hello-World repository won't return many labels. Try running it on one of your own repositories that does use labels, and you'll likely see a difference.
query FindIssueID {
repository(owner:"octocat", name:"Hello-World") {
issue(number:349) {
id
}
}
}
mutation AddReactionToIssue {
addReaction(input:{subjectId:"MDU6SXNzdWUyMzEzOTE1NTE=",content:HOORAY}) {
reaction {
content
}
subject {
id
}
}
}
FindIssueID and AddReactionToIssue in this example), the operations will be executed as separate calls to the GraphQL endpoint. It's not possible to perform a query at the same time as a mutation, or vice versa.
Let's walk through the example. The task sounds simple: add an emoji reaction to an issue.
So how do we know to begin with a query? We don't, yet.
Because we want to modify data on the server (attach an emoji to an issue), we begin by searching the schema for a helpful mutation. The reference docs show the addReaction mutation, with this description: Adds a reaction to a subject. Perfect!
The docs for the mutation list three input fields:
●
clientMutationId (String)
●
subjectId (ID!)
●
content (ReactionContent!)
The !s indicate that subjectId and content are required fields. A required content makes sense: we want to add a reaction, so we'll need to specify which emoji to use.
But why is subjectId required? It's because the subjectId is the only way to identify which issue in which repository to react to.
This is why we start this example with a query: to get the ID.
Let's examine the query line by line:
query FindIssueID {
Here we're performing a query, and we name it FindIssueID. Note that naming a query is optional; we give it a name here so that we can include it in same Explorer window as the mutation.
repository(owner:"octocat", name:"Hello-World") {
We specify the repository by querying the repository object and passing owner and name arguments.
issue(number:349) {
We specify the issue to react to by querying the issue object and passing a number argument.
id
This is where we retrieve the idofhttps://github.com/octocat/Hello-World/issues/349 to pass as the subjectId.
When we run the query, we get the id: MDU6SXNzdWUyMzEzOTE1NTE=
Note: The idreturned in the query is the value we'll pass as the subjectID in the mutation. Neither the docs nor schema introspection will indicate this relationship; you'll need to understand the concepts behind the names to figure this out.
With the ID known, we can proceed with the mutation:
mutation AddReactionToIssue {
Here we're performing a mutation, and we name it AddReactionToIssue. As with queries, naming a mutation is optional; we give it a name here so we can include it in the same Explorer window as the query.
addReaction(input:{subjectId:"MDU6SXNzdWUyMzEzOTE1NTE=",content:HOORAY}) {
Let's examine this line:
●
addReaction is the name of the mutation.
●
input is the required argument key. This will always be input for a mutation.
●
{subjectId:"MDU6SXNzdWUyMzEzOTE1NTE=",content:HOORAY} is the required argument value. This will always be an input object (hence the curly braces) composed of input fields (subjectId and content in this case) for a mutation.
How do we know which value to use for the content? The addReaction docs tell us the content field has the type ReactionContent, which is an enum because only certain emoji reactions are supported on GitHub issues. These are the allowed values for reactions (note some values differ from their corresponding emoji names):
| content | emoji |
|---|---|
+1 |
 |
-1 |
 |
laugh |
 |
confused |
 |
heart |
 |
hooray |
 |
rocket |
 |
eyes |
 |
addReaction docs, which three possible return fields:
●
clientMutationId (String)
●
reaction (Reaction!)
●
subject (Reactable!)
In this example, we return the two required fields (reaction and subject), both of which have required subfields (respectively, content and id).
When we run the mutation, this is the response:
{
"data": {
"addReaction": {
"reaction": {
"content": "HOORAY"
},
"subject": {
"id": "MDU6SXNzdWUyMTc5NTQ0OTc="
}
}
}
}
mutation($myVar:AddReactionInput!) {
addReaction(input:$myVar) {
reaction {
content
}
subject {
id
}
}
}
variables {
"myVar": {
"subjectId":"MDU6SXNzdWUyMTc5NTQ0OTc=",
"content":"HOORAY"
}
}
content field value in the earlier example (where it's used directly in the mutation) does not have quotes around HOORAY, but it does have quotes when used in the variable. There's a reason for this:
●When you use content directly in the mutation, the schema expects the value to be of type ReactionContent, which is an enum, not a string. Schema validation will throw an error if you add quotes around the enum value, as quotes are reserved for strings.
●When you use content in a variable, the variables section must be valid JSON, so the quotes are required. Schema validation correctly interprets the ReactionContent type when the variable is passed into the mutation during execution.
For more information on the difference between enums and strings, see the official GraphQL spec.