Returns a token that you can pass to the config script. The token expires after one hour.
You must authenticate using an access token with the admin:org scope to use this endpoint.
Configure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/octo-org --token TOKEN\nReturns a token that you can pass to the config script. The token expires after one hour.
You must authenticate using an access token with the admin:org scope to use this endpoint.
Example using registration token:
\nConfigure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/octo-org --token TOKEN\nReturns a token that you can pass to the config script to remove a self-hosted runner from an organization. The token expires after one hour.
You must authenticate using an access token with the admin:org scope to use this endpoint.
To remove your self-hosted runner from an organization, replace TOKEN with the remove token provided by this\nendpoint.
./config.sh remove --token TOKEN\nReturns a token that you can pass to the config script to remove a self-hosted runner from an organization. The token expires after one hour.
You must authenticate using an access token with the admin:org scope to use this endpoint.
Example using remove token:
\nTo remove your self-hosted runner from an organization, replace TOKEN with the remove token provided by this\nendpoint.
./config.sh remove --token TOKEN\nReturns a token that you can pass to the config script. The token expires after one hour. You must authenticate\nusing an access token with the repo scope to use this endpoint.
Configure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/octo-org/octo-repo-artifacts --token TOKEN\nReturns a token that you can pass to the config script. The token expires after one hour. You must authenticate using an access token with the repo scope to use this endpoint.
Example using registration token:
\nConfigure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/octo-org/octo-repo-artifacts --token TOKEN\nReturns a token that you can pass to remove a self-hosted runner from a repository. The token expires after one hour.\nYou must authenticate using an access token with the repo scope to use this endpoint.
To remove your self-hosted runner from a repository, replace TOKEN with the remove token provided by this endpoint.
\n./config.sh remove --token TOKEN\nReturns a token that you can pass to remove a self-hosted runner from a repository. The token expires after one hour.\nYou must authenticate using an access token with the repo scope to use this endpoint.
Example using remove token:
\nTo remove your self-hosted runner from a repository, replace TOKEN with the remove token provided by this endpoint.
\n./config.sh remove --token TOKEN\nCreates or updates a repository secret with an encrypted value. Encrypt your secret using\nLibSodium. You must authenticate using an access\ntoken with the repo scope to use this endpoint. GitHub Apps must have write access to the codespaces_secrets\nrepository permission to use this endpoint.
Encrypt your secret using the libsodium-wrappers library.
\nconst sodium = require('libsodium-wrappers')\nconst secret = 'plain-text-secret' // replace with the secret you want to encrypt\nconst key = 'base64-encoded-public-key' // replace with the Base64 encoded public key\n\n//Check if libsodium is ready and then proceed.\nsodium.ready.then(() => {\n // Convert Secret & Base64 key to Uint8Array.\n let binkey = sodium.from_base64(key, sodium.base64_variants.ORIGINAL)\n let binsec = sodium.from_string(secret)\n\n //Encrypt the secret using LibSodium\n let encBytes = sodium.crypto_box_seal(binsec, binkey)\n\n // Convert encrypted Uint8Array to Base64\n let output = sodium.to_base64(encBytes, sodium.base64_variants.ORIGINAL)\n\n console.log(output)\n});\nEncrypt your secret using pynacl with Python 3.
\nfrom base64 import b64encode\nfrom nacl import encoding, public\n\ndef encrypt(public_key: str, secret_value: str) -> str:\n \"\"\"Encrypt a Unicode string using the public key.\"\"\"\n public_key = public.PublicKey(public_key.encode(\"utf-8\"), encoding.Base64Encoder())\n sealed_box = public.SealedBox(public_key)\n encrypted = sealed_box.encrypt(secret_value.encode(\"utf-8\"))\n return b64encode(encrypted).decode(\"utf-8\")\nEncrypt your secret using the Sodium.Core package.
\nvar secretValue = System.Text.Encoding.UTF8.GetBytes(\"mySecret\");\nvar publicKey = Convert.FromBase64String(\"2Sg8iYjAxxmI2LvUXpJjkYrMxURPc8r+dB7TJyvvcCU=\");\n\nvar sealedPublicKeyBox = Sodium.SealedPublicKeyBox.Create(secretValue, publicKey);\n\nConsole.WriteLine(Convert.ToBase64String(sealedPublicKeyBox));\nEncrypt your secret using the rbnacl gem.
\nrequire \"rbnacl\"\nrequire \"base64\"\n\nkey = Base64.decode64(\"+ZYvJDZMHUfBkJdyq5Zm9SKqeuBQ4sj+6sfjlH4CgG0=\")\npublic_key = RbNaCl::PublicKey.new(key)\n\nbox = RbNaCl::Boxes::Sealed.from_public_key(public_key)\nencrypted_secret = box.encrypt(\"my_secret\")\n\n# Print the base64 encoded secret\nputs Base64.strict_encode64(encrypted_secret)\nCreates or updates a repository secret with an encrypted value. Encrypt your secret using\nLibSodium. You must authenticate using an access\ntoken with the repo scope to use this endpoint. GitHub Apps must have write access to the codespaces_secrets\nrepository permission to use this endpoint.
Example of encrypting a secret using Node.js:
\nEncrypt your secret using the libsodium-wrappers library.
\nconst sodium = require('libsodium-wrappers')\nconst secret = 'plain-text-secret' // replace with the secret you want to encrypt\nconst key = 'base64-encoded-public-key' // replace with the Base64 encoded public key\n\n//Check if libsodium is ready and then proceed.\nsodium.ready.then(() => {\n // Convert Secret & Base64 key to Uint8Array.\n let binkey = sodium.from_base64(key, sodium.base64_variants.ORIGINAL)\n let binsec = sodium.from_string(secret)\n\n //Encrypt the secret using LibSodium\n let encBytes = sodium.crypto_box_seal(binsec, binkey)\n\n // Convert encrypted Uint8Array to Base64\n let output = sodium.to_base64(encBytes, sodium.base64_variants.ORIGINAL)\n\n console.log(output)\n});\nExample of encrypting a secret using Python:
\nEncrypt your secret using pynacl with Python 3.
\nfrom base64 import b64encode\nfrom nacl import encoding, public\n\ndef encrypt(public_key: str, secret_value: str) -> str:\n \"\"\"Encrypt a Unicode string using the public key.\"\"\"\n public_key = public.PublicKey(public_key.encode(\"utf-8\"), encoding.Base64Encoder())\n sealed_box = public.SealedBox(public_key)\n encrypted = sealed_box.encrypt(secret_value.encode(\"utf-8\"))\n return b64encode(encrypted).decode(\"utf-8\")\nExample of encrypting a secret using C#:
\nEncrypt your secret using the Sodium.Core package.
\nvar secretValue = System.Text.Encoding.UTF8.GetBytes(\"mySecret\");\nvar publicKey = Convert.FromBase64String(\"2Sg8iYjAxxmI2LvUXpJjkYrMxURPc8r+dB7TJyvvcCU=\");\n\nvar sealedPublicKeyBox = Sodium.SealedPublicKeyBox.Create(secretValue, publicKey);\n\nConsole.WriteLine(Convert.ToBase64String(sealedPublicKeyBox));\nExample of encrypting a secret using Ruby:
\nEncrypt your secret using the rbnacl gem.
\nrequire \"rbnacl\"\nrequire \"base64\"\n\nkey = Base64.decode64(\"+ZYvJDZMHUfBkJdyq5Zm9SKqeuBQ4sj+6sfjlH4CgG0=\")\npublic_key = RbNaCl::PublicKey.new(key)\n\nbox = RbNaCl::Boxes::Sealed.from_public_key(public_key)\nencrypted_secret = box.encrypt(\"my_secret\")\n\n# Print the base64 encoded secret\nputs Base64.strict_encode64(encrypted_secret)\nDeployments offer a few configurable parameters with certain defaults.
\nThe ref parameter can be any named branch, tag, or SHA. At GitHub we often deploy branches and verify them\nbefore we merge a pull request.
The environment parameter allows deployments to be issued to different runtime environments. Teams often have\nmultiple environments for verifying their applications, such as production, staging, and qa. This parameter\nmakes it easier to track which environments have requested deployments. The default environment is production.
The auto_merge parameter is used to ensure that the requested ref is not behind the repository's default branch. If\nthe ref is behind the default branch for the repository, we will attempt to merge it for you. If the merge succeeds,\nthe API will return a successful merge commit. If merge conflicts prevent the merge from succeeding, the API will\nreturn a failure response.
By default, commit statuses for every submitted context must be in a success\nstate. The required_contexts parameter allows you to specify a subset of contexts that must be success, or to\nspecify contexts that have not yet been submitted. You are not required to use commit statuses to deploy. If you do\nnot require any contexts or create any commit statuses, the deployment will always succeed.
The payload parameter is available for any extra information that a deployment system might need. It is a JSON text\nfield that will be passed on when a deployment event is dispatched.
The task parameter is used by the deployment system to allow different execution paths. In the web world this might\nbe deploy:migrations to run schema changes on the system. In the compiled world this could be a flag to compile an\napplication with debugging enabled.
Users with repo or repo_deployment scopes can create a deployment for a given ref.
You will see this response when GitHub automatically merges the base branch into the topic branch instead of creating\na deployment. This auto-merge happens when:
\nmaster in the response exampleIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.
\nThis error happens when the auto_merge option is enabled and when the default branch (in this case master), can't\nbe merged into the branch that's being deployed (in this case topic-branch), due to merge conflicts.
This error happens when the required_contexts parameter indicates that one or more contexts need to have a success\nstatus for the commit to be deployed, but one or more of the required contexts do not have a state of success.
Deployments offer a few configurable parameters with certain defaults.
\nThe ref parameter can be any named branch, tag, or SHA. At GitHub we often deploy branches and verify them\nbefore we merge a pull request.
The environment parameter allows deployments to be issued to different runtime environments. Teams often have\nmultiple environments for verifying their applications, such as production, staging, and qa. This parameter\nmakes it easier to track which environments have requested deployments. The default environment is production.
The auto_merge parameter is used to ensure that the requested ref is not behind the repository's default branch. If\nthe ref is behind the default branch for the repository, we will attempt to merge it for you. If the merge succeeds,\nthe API will return a successful merge commit. If merge conflicts prevent the merge from succeeding, the API will\nreturn a failure response.
By default, commit statuses for every submitted context must be in a success\nstate. The required_contexts parameter allows you to specify a subset of contexts that must be success, or to\nspecify contexts that have not yet been submitted. You are not required to use commit statuses to deploy. If you do\nnot require any contexts or create any commit statuses, the deployment will always succeed.
The payload parameter is available for any extra information that a deployment system might need. It is a JSON text\nfield that will be passed on when a deployment event is dispatched.
The task parameter is used by the deployment system to allow different execution paths. In the web world this might\nbe deploy:migrations to run schema changes on the system. In the compiled world this could be a flag to compile an\napplication with debugging enabled.
Users with repo or repo_deployment scopes can create a deployment for a given ref.
Merged branch response:
\nYou will see this response when GitHub automatically merges the base branch into the topic branch instead of creating\na deployment. This auto-merge happens when:
\nmaster in the response exampleIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.
\nMerge conflict response:
\nThis error happens when the auto_merge option is enabled and when the default branch (in this case master), can't\nbe merged into the branch that's being deployed (in this case topic-branch), due to merge conflicts.
Failed commit status checks:
\nThis error happens when the required_contexts parameter indicates that one or more contexts need to have a success\nstatus for the commit to be deployed, but one or more of the required contexts do not have a state of success.
Gets the contents of a file or directory in a repository. Specify the file path or directory in :path. If you omit\n:path, you will receive the contents of the repository's root directory. See the description below regarding what the API response includes for directories.
Files and symlinks support a custom media type for\nretrieving the raw content or rendered HTML (when supported). All content types support a custom media\ntype to ensure the content is returned in a consistent\nobject format.
\nNotes:
\nIf the requested file's size is:
\nraw or object custom media types are supported. Both will work as normal, except that when using the object media type, the content field will be an empty string and the encoding field will be \"none\". To get the contents of these larger files, use the raw media type.The response will be an array of objects, one object for each item in the directory.\nWhen listing the contents of a directory, submodules have their \"type\" specified as \"file\". Logically, the value\nshould be \"submodule\". This behavior exists in API v3 for backwards compatibility purposes.\nIn the next major version of the API, the type will be returned as \"submodule\".
\nIf the requested :path points to a symlink, and the symlink's target is a normal file in the repository, then the\nAPI responds with the content of the file (in the format shown in the example. Otherwise, the API responds with an object\ndescribing the symlink itself.
The submodule_git_url identifies the location of the submodule repository, and the sha identifies a specific\ncommit within the submodule repository. Git uses the given URL when cloning the submodule repository, and checks out\nthe submodule at that specific commit.
If the submodule repository is not hosted on github.com, the Git URLs (git_url and _links[\"git\"]) and the\ngithub.com URLs (html_url and _links[\"html\"]) will have null values.
Gets the contents of a file or directory in a repository. Specify the file path or directory in :path. If you omit\n:path, you will receive the contents of the repository's root directory. See the description below regarding what the API response includes for directories.
Files and symlinks support a custom media type for\nretrieving the raw content or rendered HTML (when supported). All content types support a custom media\ntype to ensure the content is returned in a consistent\nobject format.
\nNotes:
\nTo get a repository's contents recursively, you can recursively get the tree.
\nThis API has an upper limit of 1,000 files for a directory. If you need to retrieve more files, use the Git Trees\nAPI.
\nDownload URLs expire and are meant to be used just once. To ensure the download URL does not expire, please use the contents API to obtain a fresh download URL for each download.\nSize limits:\nIf the requested file's size is:
\n1 MB or smaller: All features of this endpoint are supported.
\nBetween 1-100 MB: Only the raw or object custom media types are supported. Both will work as normal, except that when using the object media type, the content field will be an empty string and the encoding field will be \"none\". To get the contents of these larger files, use the raw media type.
Greater than 100 MB: This endpoint is not supported.
\nIf the content is a directory:\nThe response will be an array of objects, one object for each item in the directory.\nWhen listing the contents of a directory, submodules have their \"type\" specified as \"file\". Logically, the value\nshould be \"submodule\". This behavior exists in API v3 for backwards compatibility purposes.\nIn the next major version of the API, the type will be returned as \"submodule\".
\n If the content is a symlink:\nIf the requested :path points to a symlink, and the symlink's target is a normal file in the repository, then the\nAPI responds with the content of the file (in the format shown in the example. Otherwise, the API responds with an object\ndescribing the symlink itself.
If the content is a submodule:\nThe submodule_git_url identifies the location of the submodule repository, and the sha identifies a specific\ncommit within the submodule repository. Git uses the given URL when cloning the submodule repository, and checks out\nthe submodule at that specific commit.
If the submodule repository is not hosted on github.com, the Git URLs (git_url and _links[\"git\"]) and the\ngithub.com URLs (html_url and _links[\"html\"]) will have null values.
Searches for query terms inside of a file. This method returns up to 100 results per page.
\nWhen searching for code, you can get text match metadata for the file content and file path fields when you pass the text-match media type. For more details about how to receive highlighted search results, see Text match metadata.
For example, if you want to find the definition of the addClass function inside jQuery repository, your query would look something like this:
q=addClass+in:file+language:js+repo:jquery/jquery
This query searches for the keyword addClass within a file's contents. The query limits the search to files where the language is JavaScript in the jquery/jquery repository.
Due to the complexity of searching code, there are a few restrictions on how searches are performed:
\nmaster branch.language:go is not valid, while amazing language:go is.This endpoint requires you to authenticate and limits you to 10 requests per minute.
", + "descriptionHTML": "Searches for query terms inside of a file. This method returns up to 100 results per page.
\nWhen searching for code, you can get text match metadata for the file content and file path fields when you pass the text-match media type. For more details about how to receive highlighted search results, see Text match metadata.
For example, if you want to find the definition of the addClass function inside jQuery repository, your query would look something like this:
q=addClass+in:file+language:js+repo:jquery/jquery
This query searches for the keyword addClass within a file's contents. The query limits the search to files where the language is JavaScript in the jquery/jquery repository.
Considerations for code search:
\nDue to the complexity of searching code, there are a few restrictions on how searches are performed:
\nmaster branch.language:go is not valid, while amazing language:go is.This endpoint requires you to authenticate and limits you to 10 requests per minute.
", "statusCodes": [ { "httpStatusCode": "200", diff --git a/src/rest/data/ghae/schema.json b/src/rest/data/ghae/schema.json index c7803c1e1e..14cb00151d 100644 --- a/src/rest/data/ghae/schema.json +++ b/src/rest/data/ghae/schema.json @@ -10183,7 +10183,7 @@ } ], "previews": [], - "descriptionHTML": "Returns a token that you can pass to the config script. The token expires after one hour.
You must authenticate using an access token with the admin:enterprise scope to use this endpoint.
Configure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/enterprises/octo-enterprise --token TOKEN\nReturns a token that you can pass to the config script. The token expires after one hour.
You must authenticate using an access token with the admin:enterprise scope to use this endpoint.
Example using registration token:
\nConfigure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/enterprises/octo-enterprise --token TOKEN\nReturns a token that you can pass to the config script to remove a self-hosted runner from an enterprise. The token expires after one hour.
You must authenticate using an access token with the admin:enterprise scope to use this endpoint.
To remove your self-hosted runner from an enterprise, replace TOKEN with the remove token provided by this\nendpoint.
./config.sh remove --token TOKEN\nReturns a token that you can pass to the config script to remove a self-hosted runner from an enterprise. The token expires after one hour.
You must authenticate using an access token with the admin:enterprise scope to use this endpoint.
Example using remove token:
\nTo remove your self-hosted runner from an enterprise, replace TOKEN with the remove token provided by this\nendpoint.
./config.sh remove --token TOKEN\nReturns a token that you can pass to the config script. The token expires after one hour.
You must authenticate using an access token with the admin:org scope to use this endpoint.
Configure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/octo-org --token TOKEN\nReturns a token that you can pass to the config script. The token expires after one hour.
You must authenticate using an access token with the admin:org scope to use this endpoint.
Example using registration token:
\nConfigure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/octo-org --token TOKEN\nReturns a token that you can pass to the config script to remove a self-hosted runner from an organization. The token expires after one hour.
You must authenticate using an access token with the admin:org scope to use this endpoint.
To remove your self-hosted runner from an organization, replace TOKEN with the remove token provided by this\nendpoint.
./config.sh remove --token TOKEN\nReturns a token that you can pass to the config script to remove a self-hosted runner from an organization. The token expires after one hour.
You must authenticate using an access token with the admin:org scope to use this endpoint.
Example using remove token:
\nTo remove your self-hosted runner from an organization, replace TOKEN with the remove token provided by this\nendpoint.
./config.sh remove --token TOKEN\nReturns a token that you can pass to the config script. The token expires after one hour. You must authenticate\nusing an access token with the repo scope to use this endpoint.
Configure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/octo-org/octo-repo-artifacts --token TOKEN\nReturns a token that you can pass to the config script. The token expires after one hour. You must authenticate using an access token with the repo scope to use this endpoint.
Example using registration token:
\nConfigure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/octo-org/octo-repo-artifacts --token TOKEN\nReturns a token that you can pass to remove a self-hosted runner from a repository. The token expires after one hour.\nYou must authenticate using an access token with the repo scope to use this endpoint.
To remove your self-hosted runner from a repository, replace TOKEN with the remove token provided by this endpoint.
\n./config.sh remove --token TOKEN\nReturns a token that you can pass to remove a self-hosted runner from a repository. The token expires after one hour.\nYou must authenticate using an access token with the repo scope to use this endpoint.
Example using remove token:
\nTo remove your self-hosted runner from a repository, replace TOKEN with the remove token provided by this endpoint.
\n./config.sh remove --token TOKEN\nDeployments offer a few configurable parameters with certain defaults.
\nThe ref parameter can be any named branch, tag, or SHA. At GitHub AE we often deploy branches and verify them\nbefore we merge a pull request.
The environment parameter allows deployments to be issued to different runtime environments. Teams often have\nmultiple environments for verifying their applications, such as production, staging, and qa. This parameter\nmakes it easier to track which environments have requested deployments. The default environment is production.
The auto_merge parameter is used to ensure that the requested ref is not behind the repository's default branch. If\nthe ref is behind the default branch for the repository, we will attempt to merge it for you. If the merge succeeds,\nthe API will return a successful merge commit. If merge conflicts prevent the merge from succeeding, the API will\nreturn a failure response.
By default, commit statuses for every submitted context must be in a success\nstate. The required_contexts parameter allows you to specify a subset of contexts that must be success, or to\nspecify contexts that have not yet been submitted. You are not required to use commit statuses to deploy. If you do\nnot require any contexts or create any commit statuses, the deployment will always succeed.
The payload parameter is available for any extra information that a deployment system might need. It is a JSON text\nfield that will be passed on when a deployment event is dispatched.
The task parameter is used by the deployment system to allow different execution paths. In the web world this might\nbe deploy:migrations to run schema changes on the system. In the compiled world this could be a flag to compile an\napplication with debugging enabled.
Users with repo or repo_deployment scopes can create a deployment for a given ref.
You will see this response when GitHub automatically merges the base branch into the topic branch instead of creating\na deployment. This auto-merge happens when:
\nmaster in the response exampleIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.
\nThis error happens when the auto_merge option is enabled and when the default branch (in this case master), can't\nbe merged into the branch that's being deployed (in this case topic-branch), due to merge conflicts.
This error happens when the required_contexts parameter indicates that one or more contexts need to have a success\nstatus for the commit to be deployed, but one or more of the required contexts do not have a state of success.
Deployments offer a few configurable parameters with certain defaults.
\nThe ref parameter can be any named branch, tag, or SHA. At GitHub AE we often deploy branches and verify them\nbefore we merge a pull request.
The environment parameter allows deployments to be issued to different runtime environments. Teams often have\nmultiple environments for verifying their applications, such as production, staging, and qa. This parameter\nmakes it easier to track which environments have requested deployments. The default environment is production.
The auto_merge parameter is used to ensure that the requested ref is not behind the repository's default branch. If\nthe ref is behind the default branch for the repository, we will attempt to merge it for you. If the merge succeeds,\nthe API will return a successful merge commit. If merge conflicts prevent the merge from succeeding, the API will\nreturn a failure response.
By default, commit statuses for every submitted context must be in a success\nstate. The required_contexts parameter allows you to specify a subset of contexts that must be success, or to\nspecify contexts that have not yet been submitted. You are not required to use commit statuses to deploy. If you do\nnot require any contexts or create any commit statuses, the deployment will always succeed.
The payload parameter is available for any extra information that a deployment system might need. It is a JSON text\nfield that will be passed on when a deployment event is dispatched.
The task parameter is used by the deployment system to allow different execution paths. In the web world this might\nbe deploy:migrations to run schema changes on the system. In the compiled world this could be a flag to compile an\napplication with debugging enabled.
Users with repo or repo_deployment scopes can create a deployment for a given ref.
Merged branch response:
\nYou will see this response when GitHub automatically merges the base branch into the topic branch instead of creating\na deployment. This auto-merge happens when:
\nmaster in the response exampleIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.
\nMerge conflict response:
\nThis error happens when the auto_merge option is enabled and when the default branch (in this case master), can't\nbe merged into the branch that's being deployed (in this case topic-branch), due to merge conflicts.
Failed commit status checks:
\nThis error happens when the required_contexts parameter indicates that one or more contexts need to have a success\nstatus for the commit to be deployed, but one or more of the required contexts do not have a state of success.
Gets the contents of a file or directory in a repository. Specify the file path or directory in :path. If you omit\n:path, you will receive the contents of the repository's root directory. See the description below regarding what the API response includes for directories.
Files and symlinks support a custom media type for\nretrieving the raw content or rendered HTML (when supported). All content types support a custom media\ntype to ensure the content is returned in a consistent\nobject format.
\nNotes:
\nThe response will be an array of objects, one object for each item in the directory.\nWhen listing the contents of a directory, submodules have their \"type\" specified as \"file\". Logically, the value\nshould be \"submodule\". This behavior exists in API v3 for backwards compatibility purposes.\nIn the next major version of the API, the type will be returned as \"submodule\".
\nIf the requested :path points to a symlink, and the symlink's target is a normal file in the repository, then the\nAPI responds with the content of the file (in the format shown in the example. Otherwise, the API responds with an object\ndescribing the symlink itself.
The submodule_git_url identifies the location of the submodule repository, and the sha identifies a specific\ncommit within the submodule repository. Git uses the given URL when cloning the submodule repository, and checks out\nthe submodule at that specific commit.
If the submodule repository is not hosted on github.com, the Git URLs (git_url and _links[\"git\"]) and the\ngithub.com URLs (html_url and _links[\"html\"]) will have null values.
Gets the contents of a file or directory in a repository. Specify the file path or directory in :path. If you omit\n:path, you will receive the contents of the repository's root directory. See the description below regarding what the API response includes for directories.
Files and symlinks support a custom media type for\nretrieving the raw content or rendered HTML (when supported). All content types support a custom media\ntype to ensure the content is returned in a consistent\nobject format.
\nNotes:
\nTo get a repository's contents recursively, you can recursively get the tree.
\nThis API has an upper limit of 1,000 files for a directory. If you need to retrieve more files, use the Git Trees\nAPI.
\nDownload URLs expire and are meant to be used just once. To ensure the download URL does not expire, please use the contents API to obtain a fresh download URL for each download.
\nThis API supports files up to 1 megabyte in size.
\nIf the content is a directory:\nThe response will be an array of objects, one object for each item in the directory.\nWhen listing the contents of a directory, submodules have their \"type\" specified as \"file\". Logically, the value\nshould be \"submodule\". This behavior exists in API v3 for backwards compatibility purposes.\nIn the next major version of the API, the type will be returned as \"submodule\".
\n If the content is a symlink:\nIf the requested :path points to a symlink, and the symlink's target is a normal file in the repository, then the\nAPI responds with the content of the file (in the format shown in the example. Otherwise, the API responds with an object\ndescribing the symlink itself.
If the content is a submodule:\nThe submodule_git_url identifies the location of the submodule repository, and the sha identifies a specific\ncommit within the submodule repository. Git uses the given URL when cloning the submodule repository, and checks out\nthe submodule at that specific commit.
If the submodule repository is not hosted on github.com, the Git URLs (git_url and _links[\"git\"]) and the\ngithub.com URLs (html_url and _links[\"html\"]) will have null values.
Searches for query terms inside of a file. This method returns up to 100 results per page.
\nWhen searching for code, you can get text match metadata for the file content and file path fields when you pass the text-match media type. For more details about how to receive highlighted search results, see Text match metadata.
For example, if you want to find the definition of the addClass function inside jQuery repository, your query would look something like this:
q=addClass+in:file+language:js+repo:jquery/jquery
This query searches for the keyword addClass within a file's contents. The query limits the search to files where the language is JavaScript in the jquery/jquery repository.
Due to the complexity of searching code, there are a few restrictions on how searches are performed:
\nmaster branch.language:go is not valid, while amazing language:go is.This endpoint requires you to authenticate and limits you to 10 requests per minute.
", + "descriptionHTML": "Searches for query terms inside of a file. This method returns up to 100 results per page.
\nWhen searching for code, you can get text match metadata for the file content and file path fields when you pass the text-match media type. For more details about how to receive highlighted search results, see Text match metadata.
For example, if you want to find the definition of the addClass function inside jQuery repository, your query would look something like this:
q=addClass+in:file+language:js+repo:jquery/jquery
This query searches for the keyword addClass within a file's contents. The query limits the search to files where the language is JavaScript in the jquery/jquery repository.
Considerations for code search:
\nDue to the complexity of searching code, there are a few restrictions on how searches are performed:
\nmaster branch.language:go is not valid, while amazing language:go is.This endpoint requires you to authenticate and limits you to 10 requests per minute.
", "statusCodes": [ { "httpStatusCode": "200", diff --git a/src/rest/data/ghec-2022-11-28/schema.json b/src/rest/data/ghec-2022-11-28/schema.json index a854fbc3e2..c8a28d8ab9 100644 --- a/src/rest/data/ghec-2022-11-28/schema.json +++ b/src/rest/data/ghec-2022-11-28/schema.json @@ -14886,7 +14886,7 @@ } ], "previews": [], - "descriptionHTML": "Returns a token that you can pass to the config script. The token expires after one hour.
You must authenticate using an access token with the manage_runners:enterprise scope to use this endpoint.
Configure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/enterprises/octo-enterprise --token TOKEN\nReturns a token that you can pass to the config script. The token expires after one hour.
You must authenticate using an access token with the manage_runners:enterprise scope to use this endpoint.
Example using registration token:
\nConfigure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/enterprises/octo-enterprise --token TOKEN\nReturns a token that you can pass to the config script to remove a self-hosted runner from an enterprise. The token expires after one hour.
You must authenticate using an access token with the manage_runners:enterprise scope to use this endpoint.
To remove your self-hosted runner from an enterprise, replace TOKEN with the remove token provided by this\nendpoint.
./config.sh remove --token TOKEN\nReturns a token that you can pass to the config script to remove a self-hosted runner from an enterprise. The token expires after one hour.
You must authenticate using an access token with the manage_runners:enterprise scope to use this endpoint.
Example using remove token:
\nTo remove your self-hosted runner from an enterprise, replace TOKEN with the remove token provided by this\nendpoint.
./config.sh remove --token TOKEN\nReturns a token that you can pass to the config script. The token expires after one hour.
You must authenticate using an access token with the admin:org scope to use this endpoint.
Configure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/octo-org --token TOKEN\nReturns a token that you can pass to the config script. The token expires after one hour.
You must authenticate using an access token with the admin:org scope to use this endpoint.
Example using registration token:
\nConfigure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/octo-org --token TOKEN\nReturns a token that you can pass to the config script to remove a self-hosted runner from an organization. The token expires after one hour.
You must authenticate using an access token with the admin:org scope to use this endpoint.
To remove your self-hosted runner from an organization, replace TOKEN with the remove token provided by this\nendpoint.
./config.sh remove --token TOKEN\nReturns a token that you can pass to the config script to remove a self-hosted runner from an organization. The token expires after one hour.
You must authenticate using an access token with the admin:org scope to use this endpoint.
Example using remove token:
\nTo remove your self-hosted runner from an organization, replace TOKEN with the remove token provided by this\nendpoint.
./config.sh remove --token TOKEN\nReturns a token that you can pass to the config script. The token expires after one hour. You must authenticate\nusing an access token with the repo scope to use this endpoint.
Configure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/octo-org/octo-repo-artifacts --token TOKEN\nReturns a token that you can pass to the config script. The token expires after one hour. You must authenticate using an access token with the repo scope to use this endpoint.
Example using registration token:
\nConfigure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/octo-org/octo-repo-artifacts --token TOKEN\nReturns a token that you can pass to remove a self-hosted runner from a repository. The token expires after one hour.\nYou must authenticate using an access token with the repo scope to use this endpoint.
To remove your self-hosted runner from a repository, replace TOKEN with the remove token provided by this endpoint.
\n./config.sh remove --token TOKEN\nReturns a token that you can pass to remove a self-hosted runner from a repository. The token expires after one hour.\nYou must authenticate using an access token with the repo scope to use this endpoint.
Example using remove token:
\nTo remove your self-hosted runner from a repository, replace TOKEN with the remove token provided by this endpoint.
\n./config.sh remove --token TOKEN\nCreates or updates a repository secret with an encrypted value. Encrypt your secret using\nLibSodium. You must authenticate using an access\ntoken with the repo scope to use this endpoint. GitHub Apps must have write access to the codespaces_secrets\nrepository permission to use this endpoint.
Encrypt your secret using the libsodium-wrappers library.
\nconst sodium = require('libsodium-wrappers')\nconst secret = 'plain-text-secret' // replace with the secret you want to encrypt\nconst key = 'base64-encoded-public-key' // replace with the Base64 encoded public key\n\n//Check if libsodium is ready and then proceed.\nsodium.ready.then(() => {\n // Convert Secret & Base64 key to Uint8Array.\n let binkey = sodium.from_base64(key, sodium.base64_variants.ORIGINAL)\n let binsec = sodium.from_string(secret)\n\n //Encrypt the secret using LibSodium\n let encBytes = sodium.crypto_box_seal(binsec, binkey)\n\n // Convert encrypted Uint8Array to Base64\n let output = sodium.to_base64(encBytes, sodium.base64_variants.ORIGINAL)\n\n console.log(output)\n});\nEncrypt your secret using pynacl with Python 3.
\nfrom base64 import b64encode\nfrom nacl import encoding, public\n\ndef encrypt(public_key: str, secret_value: str) -> str:\n \"\"\"Encrypt a Unicode string using the public key.\"\"\"\n public_key = public.PublicKey(public_key.encode(\"utf-8\"), encoding.Base64Encoder())\n sealed_box = public.SealedBox(public_key)\n encrypted = sealed_box.encrypt(secret_value.encode(\"utf-8\"))\n return b64encode(encrypted).decode(\"utf-8\")\nEncrypt your secret using the Sodium.Core package.
\nvar secretValue = System.Text.Encoding.UTF8.GetBytes(\"mySecret\");\nvar publicKey = Convert.FromBase64String(\"2Sg8iYjAxxmI2LvUXpJjkYrMxURPc8r+dB7TJyvvcCU=\");\n\nvar sealedPublicKeyBox = Sodium.SealedPublicKeyBox.Create(secretValue, publicKey);\n\nConsole.WriteLine(Convert.ToBase64String(sealedPublicKeyBox));\nEncrypt your secret using the rbnacl gem.
\nrequire \"rbnacl\"\nrequire \"base64\"\n\nkey = Base64.decode64(\"+ZYvJDZMHUfBkJdyq5Zm9SKqeuBQ4sj+6sfjlH4CgG0=\")\npublic_key = RbNaCl::PublicKey.new(key)\n\nbox = RbNaCl::Boxes::Sealed.from_public_key(public_key)\nencrypted_secret = box.encrypt(\"my_secret\")\n\n# Print the base64 encoded secret\nputs Base64.strict_encode64(encrypted_secret)\nCreates or updates a repository secret with an encrypted value. Encrypt your secret using\nLibSodium. You must authenticate using an access\ntoken with the repo scope to use this endpoint. GitHub Apps must have write access to the codespaces_secrets\nrepository permission to use this endpoint.
Example of encrypting a secret using Node.js:
\nEncrypt your secret using the libsodium-wrappers library.
\nconst sodium = require('libsodium-wrappers')\nconst secret = 'plain-text-secret' // replace with the secret you want to encrypt\nconst key = 'base64-encoded-public-key' // replace with the Base64 encoded public key\n\n//Check if libsodium is ready and then proceed.\nsodium.ready.then(() => {\n // Convert Secret & Base64 key to Uint8Array.\n let binkey = sodium.from_base64(key, sodium.base64_variants.ORIGINAL)\n let binsec = sodium.from_string(secret)\n\n //Encrypt the secret using LibSodium\n let encBytes = sodium.crypto_box_seal(binsec, binkey)\n\n // Convert encrypted Uint8Array to Base64\n let output = sodium.to_base64(encBytes, sodium.base64_variants.ORIGINAL)\n\n console.log(output)\n});\nExample of encrypting a secret using Python:
\nEncrypt your secret using pynacl with Python 3.
\nfrom base64 import b64encode\nfrom nacl import encoding, public\n\ndef encrypt(public_key: str, secret_value: str) -> str:\n \"\"\"Encrypt a Unicode string using the public key.\"\"\"\n public_key = public.PublicKey(public_key.encode(\"utf-8\"), encoding.Base64Encoder())\n sealed_box = public.SealedBox(public_key)\n encrypted = sealed_box.encrypt(secret_value.encode(\"utf-8\"))\n return b64encode(encrypted).decode(\"utf-8\")\nExample of encrypting a secret using C#:
\nEncrypt your secret using the Sodium.Core package.
\nvar secretValue = System.Text.Encoding.UTF8.GetBytes(\"mySecret\");\nvar publicKey = Convert.FromBase64String(\"2Sg8iYjAxxmI2LvUXpJjkYrMxURPc8r+dB7TJyvvcCU=\");\n\nvar sealedPublicKeyBox = Sodium.SealedPublicKeyBox.Create(secretValue, publicKey);\n\nConsole.WriteLine(Convert.ToBase64String(sealedPublicKeyBox));\nExample of encrypting a secret using Ruby:
\nEncrypt your secret using the rbnacl gem.
\nrequire \"rbnacl\"\nrequire \"base64\"\n\nkey = Base64.decode64(\"+ZYvJDZMHUfBkJdyq5Zm9SKqeuBQ4sj+6sfjlH4CgG0=\")\npublic_key = RbNaCl::PublicKey.new(key)\n\nbox = RbNaCl::Boxes::Sealed.from_public_key(public_key)\nencrypted_secret = box.encrypt(\"my_secret\")\n\n# Print the base64 encoded secret\nputs Base64.strict_encode64(encrypted_secret)\nDeployments offer a few configurable parameters with certain defaults.
\nThe ref parameter can be any named branch, tag, or SHA. At GitHub Enterprise Cloud we often deploy branches and verify them\nbefore we merge a pull request.
The environment parameter allows deployments to be issued to different runtime environments. Teams often have\nmultiple environments for verifying their applications, such as production, staging, and qa. This parameter\nmakes it easier to track which environments have requested deployments. The default environment is production.
The auto_merge parameter is used to ensure that the requested ref is not behind the repository's default branch. If\nthe ref is behind the default branch for the repository, we will attempt to merge it for you. If the merge succeeds,\nthe API will return a successful merge commit. If merge conflicts prevent the merge from succeeding, the API will\nreturn a failure response.
By default, commit statuses for every submitted context must be in a success\nstate. The required_contexts parameter allows you to specify a subset of contexts that must be success, or to\nspecify contexts that have not yet been submitted. You are not required to use commit statuses to deploy. If you do\nnot require any contexts or create any commit statuses, the deployment will always succeed.
The payload parameter is available for any extra information that a deployment system might need. It is a JSON text\nfield that will be passed on when a deployment event is dispatched.
The task parameter is used by the deployment system to allow different execution paths. In the web world this might\nbe deploy:migrations to run schema changes on the system. In the compiled world this could be a flag to compile an\napplication with debugging enabled.
Users with repo or repo_deployment scopes can create a deployment for a given ref.
You will see this response when GitHub automatically merges the base branch into the topic branch instead of creating\na deployment. This auto-merge happens when:
\nmaster in the response exampleIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.
\nThis error happens when the auto_merge option is enabled and when the default branch (in this case master), can't\nbe merged into the branch that's being deployed (in this case topic-branch), due to merge conflicts.
This error happens when the required_contexts parameter indicates that one or more contexts need to have a success\nstatus for the commit to be deployed, but one or more of the required contexts do not have a state of success.
Deployments offer a few configurable parameters with certain defaults.
\nThe ref parameter can be any named branch, tag, or SHA. At GitHub Enterprise Cloud we often deploy branches and verify them\nbefore we merge a pull request.
The environment parameter allows deployments to be issued to different runtime environments. Teams often have\nmultiple environments for verifying their applications, such as production, staging, and qa. This parameter\nmakes it easier to track which environments have requested deployments. The default environment is production.
The auto_merge parameter is used to ensure that the requested ref is not behind the repository's default branch. If\nthe ref is behind the default branch for the repository, we will attempt to merge it for you. If the merge succeeds,\nthe API will return a successful merge commit. If merge conflicts prevent the merge from succeeding, the API will\nreturn a failure response.
By default, commit statuses for every submitted context must be in a success\nstate. The required_contexts parameter allows you to specify a subset of contexts that must be success, or to\nspecify contexts that have not yet been submitted. You are not required to use commit statuses to deploy. If you do\nnot require any contexts or create any commit statuses, the deployment will always succeed.
The payload parameter is available for any extra information that a deployment system might need. It is a JSON text\nfield that will be passed on when a deployment event is dispatched.
The task parameter is used by the deployment system to allow different execution paths. In the web world this might\nbe deploy:migrations to run schema changes on the system. In the compiled world this could be a flag to compile an\napplication with debugging enabled.
Users with repo or repo_deployment scopes can create a deployment for a given ref.
Merged branch response:
\nYou will see this response when GitHub automatically merges the base branch into the topic branch instead of creating\na deployment. This auto-merge happens when:
\nmaster in the response exampleIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.
\nMerge conflict response:
\nThis error happens when the auto_merge option is enabled and when the default branch (in this case master), can't\nbe merged into the branch that's being deployed (in this case topic-branch), due to merge conflicts.
Failed commit status checks:
\nThis error happens when the required_contexts parameter indicates that one or more contexts need to have a success\nstatus for the commit to be deployed, but one or more of the required contexts do not have a state of success.
Gets the contents of a file or directory in a repository. Specify the file path or directory in :path. If you omit\n:path, you will receive the contents of the repository's root directory. See the description below regarding what the API response includes for directories.
Files and symlinks support a custom media type for\nretrieving the raw content or rendered HTML (when supported). All content types support a custom media\ntype to ensure the content is returned in a consistent\nobject format.
\nNotes:
\nIf the requested file's size is:
\nraw or object custom media types are supported. Both will work as normal, except that when using the object media type, the content field will be an empty string and the encoding field will be \"none\". To get the contents of these larger files, use the raw media type.The response will be an array of objects, one object for each item in the directory.\nWhen listing the contents of a directory, submodules have their \"type\" specified as \"file\". Logically, the value\nshould be \"submodule\". This behavior exists in API v3 for backwards compatibility purposes.\nIn the next major version of the API, the type will be returned as \"submodule\".
\nIf the requested :path points to a symlink, and the symlink's target is a normal file in the repository, then the\nAPI responds with the content of the file (in the format shown in the example. Otherwise, the API responds with an object\ndescribing the symlink itself.
The submodule_git_url identifies the location of the submodule repository, and the sha identifies a specific\ncommit within the submodule repository. Git uses the given URL when cloning the submodule repository, and checks out\nthe submodule at that specific commit.
If the submodule repository is not hosted on github.com, the Git URLs (git_url and _links[\"git\"]) and the\ngithub.com URLs (html_url and _links[\"html\"]) will have null values.
Gets the contents of a file or directory in a repository. Specify the file path or directory in :path. If you omit\n:path, you will receive the contents of the repository's root directory. See the description below regarding what the API response includes for directories.
Files and symlinks support a custom media type for\nretrieving the raw content or rendered HTML (when supported). All content types support a custom media\ntype to ensure the content is returned in a consistent\nobject format.
\nNotes:
\nTo get a repository's contents recursively, you can recursively get the tree.
\nThis API has an upper limit of 1,000 files for a directory. If you need to retrieve more files, use the Git Trees\nAPI.
\nDownload URLs expire and are meant to be used just once. To ensure the download URL does not expire, please use the contents API to obtain a fresh download URL for each download.\nSize limits:\nIf the requested file's size is:
\n1 MB or smaller: All features of this endpoint are supported.
\nBetween 1-100 MB: Only the raw or object custom media types are supported. Both will work as normal, except that when using the object media type, the content field will be an empty string and the encoding field will be \"none\". To get the contents of these larger files, use the raw media type.
Greater than 100 MB: This endpoint is not supported.
\nIf the content is a directory:\nThe response will be an array of objects, one object for each item in the directory.\nWhen listing the contents of a directory, submodules have their \"type\" specified as \"file\". Logically, the value\nshould be \"submodule\". This behavior exists in API v3 for backwards compatibility purposes.\nIn the next major version of the API, the type will be returned as \"submodule\".
\n If the content is a symlink:\nIf the requested :path points to a symlink, and the symlink's target is a normal file in the repository, then the\nAPI responds with the content of the file (in the format shown in the example. Otherwise, the API responds with an object\ndescribing the symlink itself.
If the content is a submodule:\nThe submodule_git_url identifies the location of the submodule repository, and the sha identifies a specific\ncommit within the submodule repository. Git uses the given URL when cloning the submodule repository, and checks out\nthe submodule at that specific commit.
If the submodule repository is not hosted on github.com, the Git URLs (git_url and _links[\"git\"]) and the\ngithub.com URLs (html_url and _links[\"html\"]) will have null values.
Searches for query terms inside of a file. This method returns up to 100 results per page.
\nWhen searching for code, you can get text match metadata for the file content and file path fields when you pass the text-match media type. For more details about how to receive highlighted search results, see Text match metadata.
For example, if you want to find the definition of the addClass function inside jQuery repository, your query would look something like this:
q=addClass+in:file+language:js+repo:jquery/jquery
This query searches for the keyword addClass within a file's contents. The query limits the search to files where the language is JavaScript in the jquery/jquery repository.
Due to the complexity of searching code, there are a few restrictions on how searches are performed:
\nmaster branch.language:go is not valid, while amazing language:go is.This endpoint requires you to authenticate and limits you to 10 requests per minute.
", + "descriptionHTML": "Searches for query terms inside of a file. This method returns up to 100 results per page.
\nWhen searching for code, you can get text match metadata for the file content and file path fields when you pass the text-match media type. For more details about how to receive highlighted search results, see Text match metadata.
For example, if you want to find the definition of the addClass function inside jQuery repository, your query would look something like this:
q=addClass+in:file+language:js+repo:jquery/jquery
This query searches for the keyword addClass within a file's contents. The query limits the search to files where the language is JavaScript in the jquery/jquery repository.
Considerations for code search:
\nDue to the complexity of searching code, there are a few restrictions on how searches are performed:
\nmaster branch.language:go is not valid, while amazing language:go is.This endpoint requires you to authenticate and limits you to 10 requests per minute.
", "statusCodes": [ { "httpStatusCode": "200", diff --git a/src/rest/data/ghes-3.6/schema.json b/src/rest/data/ghes-3.6/schema.json index 9f7569758e..ce5905a17e 100644 --- a/src/rest/data/ghes-3.6/schema.json +++ b/src/rest/data/ghes-3.6/schema.json @@ -13835,7 +13835,7 @@ } ], "previews": [], - "descriptionHTML": "Returns a token that you can pass to the config script. The token expires after one hour.
You must authenticate using an access token with the manage_runners:enterprise scope to use this endpoint.
Configure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/enterprises/octo-enterprise --token TOKEN\nReturns a token that you can pass to the config script. The token expires after one hour.
You must authenticate using an access token with the manage_runners:enterprise scope to use this endpoint.
Example using registration token:
\nConfigure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/enterprises/octo-enterprise --token TOKEN\nReturns a token that you can pass to the config script to remove a self-hosted runner from an enterprise. The token expires after one hour.
You must authenticate using an access token with the manage_runners:enterprise scope to use this endpoint.
To remove your self-hosted runner from an enterprise, replace TOKEN with the remove token provided by this\nendpoint.
./config.sh remove --token TOKEN\nReturns a token that you can pass to the config script to remove a self-hosted runner from an enterprise. The token expires after one hour.
You must authenticate using an access token with the manage_runners:enterprise scope to use this endpoint.
Example using remove token:
\nTo remove your self-hosted runner from an enterprise, replace TOKEN with the remove token provided by this\nendpoint.
./config.sh remove --token TOKEN\nReturns a token that you can pass to the config script. The token expires after one hour.
You must authenticate using an access token with the admin:org scope to use this endpoint.
Configure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/octo-org --token TOKEN\nReturns a token that you can pass to the config script. The token expires after one hour.
You must authenticate using an access token with the admin:org scope to use this endpoint.
Example using registration token:
\nConfigure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/octo-org --token TOKEN\nReturns a token that you can pass to the config script to remove a self-hosted runner from an organization. The token expires after one hour.
You must authenticate using an access token with the admin:org scope to use this endpoint.
To remove your self-hosted runner from an organization, replace TOKEN with the remove token provided by this\nendpoint.
./config.sh remove --token TOKEN\nReturns a token that you can pass to the config script to remove a self-hosted runner from an organization. The token expires after one hour.
You must authenticate using an access token with the admin:org scope to use this endpoint.
Example using remove token:
\nTo remove your self-hosted runner from an organization, replace TOKEN with the remove token provided by this\nendpoint.
./config.sh remove --token TOKEN\nReturns a token that you can pass to the config script. The token expires after one hour. You must authenticate\nusing an access token with the repo scope to use this endpoint.
Configure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/octo-org/octo-repo-artifacts --token TOKEN\nReturns a token that you can pass to the config script. The token expires after one hour. You must authenticate using an access token with the repo scope to use this endpoint.
Example using registration token:
\nConfigure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/octo-org/octo-repo-artifacts --token TOKEN\nReturns a token that you can pass to remove a self-hosted runner from a repository. The token expires after one hour.\nYou must authenticate using an access token with the repo scope to use this endpoint.
To remove your self-hosted runner from a repository, replace TOKEN with the remove token provided by this endpoint.
\n./config.sh remove --token TOKEN\nReturns a token that you can pass to remove a self-hosted runner from a repository. The token expires after one hour.\nYou must authenticate using an access token with the repo scope to use this endpoint.
Example using remove token:
\nTo remove your self-hosted runner from a repository, replace TOKEN with the remove token provided by this endpoint.
\n./config.sh remove --token TOKEN\nDeployments offer a few configurable parameters with certain defaults.
\nThe ref parameter can be any named branch, tag, or SHA. At GitHub Enterprise Server we often deploy branches and verify them\nbefore we merge a pull request.
The environment parameter allows deployments to be issued to different runtime environments. Teams often have\nmultiple environments for verifying their applications, such as production, staging, and qa. This parameter\nmakes it easier to track which environments have requested deployments. The default environment is production.
The auto_merge parameter is used to ensure that the requested ref is not behind the repository's default branch. If\nthe ref is behind the default branch for the repository, we will attempt to merge it for you. If the merge succeeds,\nthe API will return a successful merge commit. If merge conflicts prevent the merge from succeeding, the API will\nreturn a failure response.
By default, commit statuses for every submitted context must be in a success\nstate. The required_contexts parameter allows you to specify a subset of contexts that must be success, or to\nspecify contexts that have not yet been submitted. You are not required to use commit statuses to deploy. If you do\nnot require any contexts or create any commit statuses, the deployment will always succeed.
The payload parameter is available for any extra information that a deployment system might need. It is a JSON text\nfield that will be passed on when a deployment event is dispatched.
The task parameter is used by the deployment system to allow different execution paths. In the web world this might\nbe deploy:migrations to run schema changes on the system. In the compiled world this could be a flag to compile an\napplication with debugging enabled.
Users with repo or repo_deployment scopes can create a deployment for a given ref.
You will see this response when GitHub automatically merges the base branch into the topic branch instead of creating\na deployment. This auto-merge happens when:
\nmaster in the response exampleIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.
\nThis error happens when the auto_merge option is enabled and when the default branch (in this case master), can't\nbe merged into the branch that's being deployed (in this case topic-branch), due to merge conflicts.
This error happens when the required_contexts parameter indicates that one or more contexts need to have a success\nstatus for the commit to be deployed, but one or more of the required contexts do not have a state of success.
Deployments offer a few configurable parameters with certain defaults.
\nThe ref parameter can be any named branch, tag, or SHA. At GitHub Enterprise Server we often deploy branches and verify them\nbefore we merge a pull request.
The environment parameter allows deployments to be issued to different runtime environments. Teams often have\nmultiple environments for verifying their applications, such as production, staging, and qa. This parameter\nmakes it easier to track which environments have requested deployments. The default environment is production.
The auto_merge parameter is used to ensure that the requested ref is not behind the repository's default branch. If\nthe ref is behind the default branch for the repository, we will attempt to merge it for you. If the merge succeeds,\nthe API will return a successful merge commit. If merge conflicts prevent the merge from succeeding, the API will\nreturn a failure response.
By default, commit statuses for every submitted context must be in a success\nstate. The required_contexts parameter allows you to specify a subset of contexts that must be success, or to\nspecify contexts that have not yet been submitted. You are not required to use commit statuses to deploy. If you do\nnot require any contexts or create any commit statuses, the deployment will always succeed.
The payload parameter is available for any extra information that a deployment system might need. It is a JSON text\nfield that will be passed on when a deployment event is dispatched.
The task parameter is used by the deployment system to allow different execution paths. In the web world this might\nbe deploy:migrations to run schema changes on the system. In the compiled world this could be a flag to compile an\napplication with debugging enabled.
Users with repo or repo_deployment scopes can create a deployment for a given ref.
Merged branch response:
\nYou will see this response when GitHub automatically merges the base branch into the topic branch instead of creating\na deployment. This auto-merge happens when:
\nmaster in the response exampleIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.
\nMerge conflict response:
\nThis error happens when the auto_merge option is enabled and when the default branch (in this case master), can't\nbe merged into the branch that's being deployed (in this case topic-branch), due to merge conflicts.
Failed commit status checks:
\nThis error happens when the required_contexts parameter indicates that one or more contexts need to have a success\nstatus for the commit to be deployed, but one or more of the required contexts do not have a state of success.
Gets the contents of a file or directory in a repository. Specify the file path or directory in :path. If you omit\n:path, you will receive the contents of the repository's root directory. See the description below regarding what the API response includes for directories.
Files and symlinks support a custom media type for\nretrieving the raw content or rendered HTML (when supported). All content types support a custom media\ntype to ensure the content is returned in a consistent\nobject format.
\nNotes:
\nIf the requested file's size is:
\nraw or object custom media types are supported. Both will work as normal, except that when using the object media type, the content field will be an empty string and the encoding field will be \"none\". To get the contents of these larger files, use the raw media type.The response will be an array of objects, one object for each item in the directory.\nWhen listing the contents of a directory, submodules have their \"type\" specified as \"file\". Logically, the value\nshould be \"submodule\". This behavior exists in API v3 for backwards compatibility purposes.\nIn the next major version of the API, the type will be returned as \"submodule\".
\nIf the requested :path points to a symlink, and the symlink's target is a normal file in the repository, then the\nAPI responds with the content of the file (in the format shown in the example. Otherwise, the API responds with an object\ndescribing the symlink itself.
The submodule_git_url identifies the location of the submodule repository, and the sha identifies a specific\ncommit within the submodule repository. Git uses the given URL when cloning the submodule repository, and checks out\nthe submodule at that specific commit.
If the submodule repository is not hosted on github.com, the Git URLs (git_url and _links[\"git\"]) and the\ngithub.com URLs (html_url and _links[\"html\"]) will have null values.
Gets the contents of a file or directory in a repository. Specify the file path or directory in :path. If you omit\n:path, you will receive the contents of the repository's root directory. See the description below regarding what the API response includes for directories.
Files and symlinks support a custom media type for\nretrieving the raw content or rendered HTML (when supported). All content types support a custom media\ntype to ensure the content is returned in a consistent\nobject format.
\nNotes:
\nTo get a repository's contents recursively, you can recursively get the tree.
\nThis API has an upper limit of 1,000 files for a directory. If you need to retrieve more files, use the Git Trees\nAPI.
\nDownload URLs expire and are meant to be used just once. To ensure the download URL does not expire, please use the contents API to obtain a fresh download URL for each download.\nSize limits:\nIf the requested file's size is:
\n1 MB or smaller: All features of this endpoint are supported.
\nBetween 1-100 MB: Only the raw or object custom media types are supported. Both will work as normal, except that when using the object media type, the content field will be an empty string and the encoding field will be \"none\". To get the contents of these larger files, use the raw media type.
Greater than 100 MB: This endpoint is not supported.
\nIf the content is a directory:\nThe response will be an array of objects, one object for each item in the directory.\nWhen listing the contents of a directory, submodules have their \"type\" specified as \"file\". Logically, the value\nshould be \"submodule\". This behavior exists in API v3 for backwards compatibility purposes.\nIn the next major version of the API, the type will be returned as \"submodule\".
\n If the content is a symlink:\nIf the requested :path points to a symlink, and the symlink's target is a normal file in the repository, then the\nAPI responds with the content of the file (in the format shown in the example. Otherwise, the API responds with an object\ndescribing the symlink itself.
If the content is a submodule:\nThe submodule_git_url identifies the location of the submodule repository, and the sha identifies a specific\ncommit within the submodule repository. Git uses the given URL when cloning the submodule repository, and checks out\nthe submodule at that specific commit.
If the submodule repository is not hosted on github.com, the Git URLs (git_url and _links[\"git\"]) and the\ngithub.com URLs (html_url and _links[\"html\"]) will have null values.
Searches for query terms inside of a file. This method returns up to 100 results per page.
\nWhen searching for code, you can get text match metadata for the file content and file path fields when you pass the text-match media type. For more details about how to receive highlighted search results, see Text match metadata.
For example, if you want to find the definition of the addClass function inside jQuery repository, your query would look something like this:
q=addClass+in:file+language:js+repo:jquery/jquery
This query searches for the keyword addClass within a file's contents. The query limits the search to files where the language is JavaScript in the jquery/jquery repository.
Due to the complexity of searching code, there are a few restrictions on how searches are performed:
\nmaster branch.language:go is not valid, while amazing language:go is.Searches for query terms inside of a file. This method returns up to 100 results per page.
\nWhen searching for code, you can get text match metadata for the file content and file path fields when you pass the text-match media type. For more details about how to receive highlighted search results, see Text match metadata.
For example, if you want to find the definition of the addClass function inside jQuery repository, your query would look something like this:
q=addClass+in:file+language:js+repo:jquery/jquery
This query searches for the keyword addClass within a file's contents. The query limits the search to files where the language is JavaScript in the jquery/jquery repository.
Considerations for code search:
\nDue to the complexity of searching code, there are a few restrictions on how searches are performed:
\nmaster branch.language:go is not valid, while amazing language:go is.Returns a token that you can pass to the config script. The token expires after one hour.
You must authenticate using an access token with the manage_runners:enterprise scope to use this endpoint.
Configure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/enterprises/octo-enterprise --token TOKEN\nReturns a token that you can pass to the config script. The token expires after one hour.
You must authenticate using an access token with the manage_runners:enterprise scope to use this endpoint.
Example using registration token:
\nConfigure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/enterprises/octo-enterprise --token TOKEN\nReturns a token that you can pass to the config script to remove a self-hosted runner from an enterprise. The token expires after one hour.
You must authenticate using an access token with the manage_runners:enterprise scope to use this endpoint.
To remove your self-hosted runner from an enterprise, replace TOKEN with the remove token provided by this\nendpoint.
./config.sh remove --token TOKEN\nReturns a token that you can pass to the config script to remove a self-hosted runner from an enterprise. The token expires after one hour.
You must authenticate using an access token with the manage_runners:enterprise scope to use this endpoint.
Example using remove token:
\nTo remove your self-hosted runner from an enterprise, replace TOKEN with the remove token provided by this\nendpoint.
./config.sh remove --token TOKEN\nReturns a token that you can pass to the config script. The token expires after one hour.
You must authenticate using an access token with the admin:org scope to use this endpoint.
Configure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/octo-org --token TOKEN\nReturns a token that you can pass to the config script. The token expires after one hour.
You must authenticate using an access token with the admin:org scope to use this endpoint.
Example using registration token:
\nConfigure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/octo-org --token TOKEN\nReturns a token that you can pass to the config script to remove a self-hosted runner from an organization. The token expires after one hour.
You must authenticate using an access token with the admin:org scope to use this endpoint.
To remove your self-hosted runner from an organization, replace TOKEN with the remove token provided by this\nendpoint.
./config.sh remove --token TOKEN\nReturns a token that you can pass to the config script to remove a self-hosted runner from an organization. The token expires after one hour.
You must authenticate using an access token with the admin:org scope to use this endpoint.
Example using remove token:
\nTo remove your self-hosted runner from an organization, replace TOKEN with the remove token provided by this\nendpoint.
./config.sh remove --token TOKEN\nReturns a token that you can pass to the config script. The token expires after one hour. You must authenticate\nusing an access token with the repo scope to use this endpoint.
Configure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/octo-org/octo-repo-artifacts --token TOKEN\nReturns a token that you can pass to the config script. The token expires after one hour. You must authenticate using an access token with the repo scope to use this endpoint.
Example using registration token:
\nConfigure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/octo-org/octo-repo-artifacts --token TOKEN\nReturns a token that you can pass to remove a self-hosted runner from a repository. The token expires after one hour.\nYou must authenticate using an access token with the repo scope to use this endpoint.
To remove your self-hosted runner from a repository, replace TOKEN with the remove token provided by this endpoint.
\n./config.sh remove --token TOKEN\nReturns a token that you can pass to remove a self-hosted runner from a repository. The token expires after one hour.\nYou must authenticate using an access token with the repo scope to use this endpoint.
Example using remove token:
\nTo remove your self-hosted runner from a repository, replace TOKEN with the remove token provided by this endpoint.
\n./config.sh remove --token TOKEN\nDeployments offer a few configurable parameters with certain defaults.
\nThe ref parameter can be any named branch, tag, or SHA. At GitHub Enterprise Server we often deploy branches and verify them\nbefore we merge a pull request.
The environment parameter allows deployments to be issued to different runtime environments. Teams often have\nmultiple environments for verifying their applications, such as production, staging, and qa. This parameter\nmakes it easier to track which environments have requested deployments. The default environment is production.
The auto_merge parameter is used to ensure that the requested ref is not behind the repository's default branch. If\nthe ref is behind the default branch for the repository, we will attempt to merge it for you. If the merge succeeds,\nthe API will return a successful merge commit. If merge conflicts prevent the merge from succeeding, the API will\nreturn a failure response.
By default, commit statuses for every submitted context must be in a success\nstate. The required_contexts parameter allows you to specify a subset of contexts that must be success, or to\nspecify contexts that have not yet been submitted. You are not required to use commit statuses to deploy. If you do\nnot require any contexts or create any commit statuses, the deployment will always succeed.
The payload parameter is available for any extra information that a deployment system might need. It is a JSON text\nfield that will be passed on when a deployment event is dispatched.
The task parameter is used by the deployment system to allow different execution paths. In the web world this might\nbe deploy:migrations to run schema changes on the system. In the compiled world this could be a flag to compile an\napplication with debugging enabled.
Users with repo or repo_deployment scopes can create a deployment for a given ref.
You will see this response when GitHub automatically merges the base branch into the topic branch instead of creating\na deployment. This auto-merge happens when:
\nmaster in the response exampleIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.
\nThis error happens when the auto_merge option is enabled and when the default branch (in this case master), can't\nbe merged into the branch that's being deployed (in this case topic-branch), due to merge conflicts.
This error happens when the required_contexts parameter indicates that one or more contexts need to have a success\nstatus for the commit to be deployed, but one or more of the required contexts do not have a state of success.
Deployments offer a few configurable parameters with certain defaults.
\nThe ref parameter can be any named branch, tag, or SHA. At GitHub Enterprise Server we often deploy branches and verify them\nbefore we merge a pull request.
The environment parameter allows deployments to be issued to different runtime environments. Teams often have\nmultiple environments for verifying their applications, such as production, staging, and qa. This parameter\nmakes it easier to track which environments have requested deployments. The default environment is production.
The auto_merge parameter is used to ensure that the requested ref is not behind the repository's default branch. If\nthe ref is behind the default branch for the repository, we will attempt to merge it for you. If the merge succeeds,\nthe API will return a successful merge commit. If merge conflicts prevent the merge from succeeding, the API will\nreturn a failure response.
By default, commit statuses for every submitted context must be in a success\nstate. The required_contexts parameter allows you to specify a subset of contexts that must be success, or to\nspecify contexts that have not yet been submitted. You are not required to use commit statuses to deploy. If you do\nnot require any contexts or create any commit statuses, the deployment will always succeed.
The payload parameter is available for any extra information that a deployment system might need. It is a JSON text\nfield that will be passed on when a deployment event is dispatched.
The task parameter is used by the deployment system to allow different execution paths. In the web world this might\nbe deploy:migrations to run schema changes on the system. In the compiled world this could be a flag to compile an\napplication with debugging enabled.
Users with repo or repo_deployment scopes can create a deployment for a given ref.
Merged branch response:
\nYou will see this response when GitHub automatically merges the base branch into the topic branch instead of creating\na deployment. This auto-merge happens when:
\nmaster in the response exampleIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.
\nMerge conflict response:
\nThis error happens when the auto_merge option is enabled and when the default branch (in this case master), can't\nbe merged into the branch that's being deployed (in this case topic-branch), due to merge conflicts.
Failed commit status checks:
\nThis error happens when the required_contexts parameter indicates that one or more contexts need to have a success\nstatus for the commit to be deployed, but one or more of the required contexts do not have a state of success.
Gets the contents of a file or directory in a repository. Specify the file path or directory in :path. If you omit\n:path, you will receive the contents of the repository's root directory. See the description below regarding what the API response includes for directories.
Files and symlinks support a custom media type for\nretrieving the raw content or rendered HTML (when supported). All content types support a custom media\ntype to ensure the content is returned in a consistent\nobject format.
\nNotes:
\nIf the requested file's size is:
\nraw or object custom media types are supported. Both will work as normal, except that when using the object media type, the content field will be an empty string and the encoding field will be \"none\". To get the contents of these larger files, use the raw media type.The response will be an array of objects, one object for each item in the directory.\nWhen listing the contents of a directory, submodules have their \"type\" specified as \"file\". Logically, the value\nshould be \"submodule\". This behavior exists in API v3 for backwards compatibility purposes.\nIn the next major version of the API, the type will be returned as \"submodule\".
\nIf the requested :path points to a symlink, and the symlink's target is a normal file in the repository, then the\nAPI responds with the content of the file (in the format shown in the example. Otherwise, the API responds with an object\ndescribing the symlink itself.
The submodule_git_url identifies the location of the submodule repository, and the sha identifies a specific\ncommit within the submodule repository. Git uses the given URL when cloning the submodule repository, and checks out\nthe submodule at that specific commit.
If the submodule repository is not hosted on github.com, the Git URLs (git_url and _links[\"git\"]) and the\ngithub.com URLs (html_url and _links[\"html\"]) will have null values.
Gets the contents of a file or directory in a repository. Specify the file path or directory in :path. If you omit\n:path, you will receive the contents of the repository's root directory. See the description below regarding what the API response includes for directories.
Files and symlinks support a custom media type for\nretrieving the raw content or rendered HTML (when supported). All content types support a custom media\ntype to ensure the content is returned in a consistent\nobject format.
\nNotes:
\nTo get a repository's contents recursively, you can recursively get the tree.
\nThis API has an upper limit of 1,000 files for a directory. If you need to retrieve more files, use the Git Trees\nAPI.
\nDownload URLs expire and are meant to be used just once. To ensure the download URL does not expire, please use the contents API to obtain a fresh download URL for each download.\nSize limits:\nIf the requested file's size is:
\n1 MB or smaller: All features of this endpoint are supported.
\nBetween 1-100 MB: Only the raw or object custom media types are supported. Both will work as normal, except that when using the object media type, the content field will be an empty string and the encoding field will be \"none\". To get the contents of these larger files, use the raw media type.
Greater than 100 MB: This endpoint is not supported.
\nIf the content is a directory:\nThe response will be an array of objects, one object for each item in the directory.\nWhen listing the contents of a directory, submodules have their \"type\" specified as \"file\". Logically, the value\nshould be \"submodule\". This behavior exists in API v3 for backwards compatibility purposes.\nIn the next major version of the API, the type will be returned as \"submodule\".
\n If the content is a symlink:\nIf the requested :path points to a symlink, and the symlink's target is a normal file in the repository, then the\nAPI responds with the content of the file (in the format shown in the example. Otherwise, the API responds with an object\ndescribing the symlink itself.
If the content is a submodule:\nThe submodule_git_url identifies the location of the submodule repository, and the sha identifies a specific\ncommit within the submodule repository. Git uses the given URL when cloning the submodule repository, and checks out\nthe submodule at that specific commit.
If the submodule repository is not hosted on github.com, the Git URLs (git_url and _links[\"git\"]) and the\ngithub.com URLs (html_url and _links[\"html\"]) will have null values.
Searches for query terms inside of a file. This method returns up to 100 results per page.
\nWhen searching for code, you can get text match metadata for the file content and file path fields when you pass the text-match media type. For more details about how to receive highlighted search results, see Text match metadata.
For example, if you want to find the definition of the addClass function inside jQuery repository, your query would look something like this:
q=addClass+in:file+language:js+repo:jquery/jquery
This query searches for the keyword addClass within a file's contents. The query limits the search to files where the language is JavaScript in the jquery/jquery repository.
Due to the complexity of searching code, there are a few restrictions on how searches are performed:
\nmaster branch.language:go is not valid, while amazing language:go is.Searches for query terms inside of a file. This method returns up to 100 results per page.
\nWhen searching for code, you can get text match metadata for the file content and file path fields when you pass the text-match media type. For more details about how to receive highlighted search results, see Text match metadata.
For example, if you want to find the definition of the addClass function inside jQuery repository, your query would look something like this:
q=addClass+in:file+language:js+repo:jquery/jquery
This query searches for the keyword addClass within a file's contents. The query limits the search to files where the language is JavaScript in the jquery/jquery repository.
Considerations for code search:
\nDue to the complexity of searching code, there are a few restrictions on how searches are performed:
\nmaster branch.language:go is not valid, while amazing language:go is.Returns a token that you can pass to the config script. The token expires after one hour.
You must authenticate using an access token with the manage_runners:enterprise scope to use this endpoint.
Configure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/enterprises/octo-enterprise --token TOKEN\nReturns a token that you can pass to the config script. The token expires after one hour.
You must authenticate using an access token with the manage_runners:enterprise scope to use this endpoint.
Example using registration token:
\nConfigure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/enterprises/octo-enterprise --token TOKEN\nReturns a token that you can pass to the config script to remove a self-hosted runner from an enterprise. The token expires after one hour.
You must authenticate using an access token with the manage_runners:enterprise scope to use this endpoint.
To remove your self-hosted runner from an enterprise, replace TOKEN with the remove token provided by this\nendpoint.
./config.sh remove --token TOKEN\nReturns a token that you can pass to the config script to remove a self-hosted runner from an enterprise. The token expires after one hour.
You must authenticate using an access token with the manage_runners:enterprise scope to use this endpoint.
Example using remove token:
\nTo remove your self-hosted runner from an enterprise, replace TOKEN with the remove token provided by this\nendpoint.
./config.sh remove --token TOKEN\nReturns a token that you can pass to the config script. The token expires after one hour.
You must authenticate using an access token with the admin:org scope to use this endpoint.
Configure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/octo-org --token TOKEN\nReturns a token that you can pass to the config script. The token expires after one hour.
You must authenticate using an access token with the admin:org scope to use this endpoint.
Example using registration token:
\nConfigure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/octo-org --token TOKEN\nReturns a token that you can pass to the config script to remove a self-hosted runner from an organization. The token expires after one hour.
You must authenticate using an access token with the admin:org scope to use this endpoint.
To remove your self-hosted runner from an organization, replace TOKEN with the remove token provided by this\nendpoint.
./config.sh remove --token TOKEN\nReturns a token that you can pass to the config script to remove a self-hosted runner from an organization. The token expires after one hour.
You must authenticate using an access token with the admin:org scope to use this endpoint.
Example using remove token:
\nTo remove your self-hosted runner from an organization, replace TOKEN with the remove token provided by this\nendpoint.
./config.sh remove --token TOKEN\nReturns a token that you can pass to the config script. The token expires after one hour. You must authenticate\nusing an access token with the repo scope to use this endpoint.
Configure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/octo-org/octo-repo-artifacts --token TOKEN\nReturns a token that you can pass to the config script. The token expires after one hour. You must authenticate using an access token with the repo scope to use this endpoint.
Example using registration token:
\nConfigure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/octo-org/octo-repo-artifacts --token TOKEN\nReturns a token that you can pass to remove a self-hosted runner from a repository. The token expires after one hour.\nYou must authenticate using an access token with the repo scope to use this endpoint.
To remove your self-hosted runner from a repository, replace TOKEN with the remove token provided by this endpoint.
\n./config.sh remove --token TOKEN\nReturns a token that you can pass to remove a self-hosted runner from a repository. The token expires after one hour.\nYou must authenticate using an access token with the repo scope to use this endpoint.
Example using remove token:
\nTo remove your self-hosted runner from a repository, replace TOKEN with the remove token provided by this endpoint.
\n./config.sh remove --token TOKEN\nDeployments offer a few configurable parameters with certain defaults.
\nThe ref parameter can be any named branch, tag, or SHA. At GitHub Enterprise Server we often deploy branches and verify them\nbefore we merge a pull request.
The environment parameter allows deployments to be issued to different runtime environments. Teams often have\nmultiple environments for verifying their applications, such as production, staging, and qa. This parameter\nmakes it easier to track which environments have requested deployments. The default environment is production.
The auto_merge parameter is used to ensure that the requested ref is not behind the repository's default branch. If\nthe ref is behind the default branch for the repository, we will attempt to merge it for you. If the merge succeeds,\nthe API will return a successful merge commit. If merge conflicts prevent the merge from succeeding, the API will\nreturn a failure response.
By default, commit statuses for every submitted context must be in a success\nstate. The required_contexts parameter allows you to specify a subset of contexts that must be success, or to\nspecify contexts that have not yet been submitted. You are not required to use commit statuses to deploy. If you do\nnot require any contexts or create any commit statuses, the deployment will always succeed.
The payload parameter is available for any extra information that a deployment system might need. It is a JSON text\nfield that will be passed on when a deployment event is dispatched.
The task parameter is used by the deployment system to allow different execution paths. In the web world this might\nbe deploy:migrations to run schema changes on the system. In the compiled world this could be a flag to compile an\napplication with debugging enabled.
Users with repo or repo_deployment scopes can create a deployment for a given ref.
You will see this response when GitHub automatically merges the base branch into the topic branch instead of creating\na deployment. This auto-merge happens when:
\nmaster in the response exampleIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.
\nThis error happens when the auto_merge option is enabled and when the default branch (in this case master), can't\nbe merged into the branch that's being deployed (in this case topic-branch), due to merge conflicts.
This error happens when the required_contexts parameter indicates that one or more contexts need to have a success\nstatus for the commit to be deployed, but one or more of the required contexts do not have a state of success.
Deployments offer a few configurable parameters with certain defaults.
\nThe ref parameter can be any named branch, tag, or SHA. At GitHub Enterprise Server we often deploy branches and verify them\nbefore we merge a pull request.
The environment parameter allows deployments to be issued to different runtime environments. Teams often have\nmultiple environments for verifying their applications, such as production, staging, and qa. This parameter\nmakes it easier to track which environments have requested deployments. The default environment is production.
The auto_merge parameter is used to ensure that the requested ref is not behind the repository's default branch. If\nthe ref is behind the default branch for the repository, we will attempt to merge it for you. If the merge succeeds,\nthe API will return a successful merge commit. If merge conflicts prevent the merge from succeeding, the API will\nreturn a failure response.
By default, commit statuses for every submitted context must be in a success\nstate. The required_contexts parameter allows you to specify a subset of contexts that must be success, or to\nspecify contexts that have not yet been submitted. You are not required to use commit statuses to deploy. If you do\nnot require any contexts or create any commit statuses, the deployment will always succeed.
The payload parameter is available for any extra information that a deployment system might need. It is a JSON text\nfield that will be passed on when a deployment event is dispatched.
The task parameter is used by the deployment system to allow different execution paths. In the web world this might\nbe deploy:migrations to run schema changes on the system. In the compiled world this could be a flag to compile an\napplication with debugging enabled.
Users with repo or repo_deployment scopes can create a deployment for a given ref.
Merged branch response:
\nYou will see this response when GitHub automatically merges the base branch into the topic branch instead of creating\na deployment. This auto-merge happens when:
\nmaster in the response exampleIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.
\nMerge conflict response:
\nThis error happens when the auto_merge option is enabled and when the default branch (in this case master), can't\nbe merged into the branch that's being deployed (in this case topic-branch), due to merge conflicts.
Failed commit status checks:
\nThis error happens when the required_contexts parameter indicates that one or more contexts need to have a success\nstatus for the commit to be deployed, but one or more of the required contexts do not have a state of success.
Gets the contents of a file or directory in a repository. Specify the file path or directory in :path. If you omit\n:path, you will receive the contents of the repository's root directory. See the description below regarding what the API response includes for directories.
Files and symlinks support a custom media type for\nretrieving the raw content or rendered HTML (when supported). All content types support a custom media\ntype to ensure the content is returned in a consistent\nobject format.
\nNotes:
\nIf the requested file's size is:
\nraw or object custom media types are supported. Both will work as normal, except that when using the object media type, the content field will be an empty string and the encoding field will be \"none\". To get the contents of these larger files, use the raw media type.The response will be an array of objects, one object for each item in the directory.\nWhen listing the contents of a directory, submodules have their \"type\" specified as \"file\". Logically, the value\nshould be \"submodule\". This behavior exists in API v3 for backwards compatibility purposes.\nIn the next major version of the API, the type will be returned as \"submodule\".
\nIf the requested :path points to a symlink, and the symlink's target is a normal file in the repository, then the\nAPI responds with the content of the file (in the format shown in the example. Otherwise, the API responds with an object\ndescribing the symlink itself.
The submodule_git_url identifies the location of the submodule repository, and the sha identifies a specific\ncommit within the submodule repository. Git uses the given URL when cloning the submodule repository, and checks out\nthe submodule at that specific commit.
If the submodule repository is not hosted on github.com, the Git URLs (git_url and _links[\"git\"]) and the\ngithub.com URLs (html_url and _links[\"html\"]) will have null values.
Gets the contents of a file or directory in a repository. Specify the file path or directory in :path. If you omit\n:path, you will receive the contents of the repository's root directory. See the description below regarding what the API response includes for directories.
Files and symlinks support a custom media type for\nretrieving the raw content or rendered HTML (when supported). All content types support a custom media\ntype to ensure the content is returned in a consistent\nobject format.
\nNotes:
\nTo get a repository's contents recursively, you can recursively get the tree.
\nThis API has an upper limit of 1,000 files for a directory. If you need to retrieve more files, use the Git Trees\nAPI.
\nDownload URLs expire and are meant to be used just once. To ensure the download URL does not expire, please use the contents API to obtain a fresh download URL for each download.\nSize limits:\nIf the requested file's size is:
\n1 MB or smaller: All features of this endpoint are supported.
\nBetween 1-100 MB: Only the raw or object custom media types are supported. Both will work as normal, except that when using the object media type, the content field will be an empty string and the encoding field will be \"none\". To get the contents of these larger files, use the raw media type.
Greater than 100 MB: This endpoint is not supported.
\nIf the content is a directory:\nThe response will be an array of objects, one object for each item in the directory.\nWhen listing the contents of a directory, submodules have their \"type\" specified as \"file\". Logically, the value\nshould be \"submodule\". This behavior exists in API v3 for backwards compatibility purposes.\nIn the next major version of the API, the type will be returned as \"submodule\".
\n If the content is a symlink:\nIf the requested :path points to a symlink, and the symlink's target is a normal file in the repository, then the\nAPI responds with the content of the file (in the format shown in the example. Otherwise, the API responds with an object\ndescribing the symlink itself.
If the content is a submodule:\nThe submodule_git_url identifies the location of the submodule repository, and the sha identifies a specific\ncommit within the submodule repository. Git uses the given URL when cloning the submodule repository, and checks out\nthe submodule at that specific commit.
If the submodule repository is not hosted on github.com, the Git URLs (git_url and _links[\"git\"]) and the\ngithub.com URLs (html_url and _links[\"html\"]) will have null values.
Searches for query terms inside of a file. This method returns up to 100 results per page.
\nWhen searching for code, you can get text match metadata for the file content and file path fields when you pass the text-match media type. For more details about how to receive highlighted search results, see Text match metadata.
For example, if you want to find the definition of the addClass function inside jQuery repository, your query would look something like this:
q=addClass+in:file+language:js+repo:jquery/jquery
This query searches for the keyword addClass within a file's contents. The query limits the search to files where the language is JavaScript in the jquery/jquery repository.
Due to the complexity of searching code, there are a few restrictions on how searches are performed:
\nmaster branch.language:go is not valid, while amazing language:go is.Searches for query terms inside of a file. This method returns up to 100 results per page.
\nWhen searching for code, you can get text match metadata for the file content and file path fields when you pass the text-match media type. For more details about how to receive highlighted search results, see Text match metadata.
For example, if you want to find the definition of the addClass function inside jQuery repository, your query would look something like this:
q=addClass+in:file+language:js+repo:jquery/jquery
This query searches for the keyword addClass within a file's contents. The query limits the search to files where the language is JavaScript in the jquery/jquery repository.
Considerations for code search:
\nDue to the complexity of searching code, there are a few restrictions on how searches are performed:
\nmaster branch.language:go is not valid, while amazing language:go is.Returns a token that you can pass to the config script. The token expires after one hour.
You must authenticate using an access token with the manage_runners:enterprise scope to use this endpoint.
Configure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/enterprises/octo-enterprise --token TOKEN\nReturns a token that you can pass to the config script. The token expires after one hour.
You must authenticate using an access token with the manage_runners:enterprise scope to use this endpoint.
Example using registration token:
\nConfigure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/enterprises/octo-enterprise --token TOKEN\nReturns a token that you can pass to the config script to remove a self-hosted runner from an enterprise. The token expires after one hour.
You must authenticate using an access token with the manage_runners:enterprise scope to use this endpoint.
To remove your self-hosted runner from an enterprise, replace TOKEN with the remove token provided by this\nendpoint.
./config.sh remove --token TOKEN\nReturns a token that you can pass to the config script to remove a self-hosted runner from an enterprise. The token expires after one hour.
You must authenticate using an access token with the manage_runners:enterprise scope to use this endpoint.
Example using remove token:
\nTo remove your self-hosted runner from an enterprise, replace TOKEN with the remove token provided by this\nendpoint.
./config.sh remove --token TOKEN\nReturns a token that you can pass to the config script. The token expires after one hour.
You must authenticate using an access token with the admin:org scope to use this endpoint.
Configure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/octo-org --token TOKEN\nReturns a token that you can pass to the config script. The token expires after one hour.
You must authenticate using an access token with the admin:org scope to use this endpoint.
Example using registration token:
\nConfigure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/octo-org --token TOKEN\nReturns a token that you can pass to the config script to remove a self-hosted runner from an organization. The token expires after one hour.
You must authenticate using an access token with the admin:org scope to use this endpoint.
To remove your self-hosted runner from an organization, replace TOKEN with the remove token provided by this\nendpoint.
./config.sh remove --token TOKEN\nReturns a token that you can pass to the config script to remove a self-hosted runner from an organization. The token expires after one hour.
You must authenticate using an access token with the admin:org scope to use this endpoint.
Example using remove token:
\nTo remove your self-hosted runner from an organization, replace TOKEN with the remove token provided by this\nendpoint.
./config.sh remove --token TOKEN\nReturns a token that you can pass to the config script. The token expires after one hour. You must authenticate\nusing an access token with the repo scope to use this endpoint.
Configure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/octo-org/octo-repo-artifacts --token TOKEN\nReturns a token that you can pass to the config script. The token expires after one hour. You must authenticate using an access token with the repo scope to use this endpoint.
Example using registration token:
\nConfigure your self-hosted runner, replacing TOKEN with the registration token provided by this endpoint.
./config.sh --url https://github.com/octo-org/octo-repo-artifacts --token TOKEN\nReturns a token that you can pass to remove a self-hosted runner from a repository. The token expires after one hour.\nYou must authenticate using an access token with the repo scope to use this endpoint.
To remove your self-hosted runner from a repository, replace TOKEN with the remove token provided by this endpoint.
\n./config.sh remove --token TOKEN\nReturns a token that you can pass to remove a self-hosted runner from a repository. The token expires after one hour.\nYou must authenticate using an access token with the repo scope to use this endpoint.
Example using remove token:
\nTo remove your self-hosted runner from a repository, replace TOKEN with the remove token provided by this endpoint.
\n./config.sh remove --token TOKEN\nDeployments offer a few configurable parameters with certain defaults.
\nThe ref parameter can be any named branch, tag, or SHA. At GitHub Enterprise Server we often deploy branches and verify them\nbefore we merge a pull request.
The environment parameter allows deployments to be issued to different runtime environments. Teams often have\nmultiple environments for verifying their applications, such as production, staging, and qa. This parameter\nmakes it easier to track which environments have requested deployments. The default environment is production.
The auto_merge parameter is used to ensure that the requested ref is not behind the repository's default branch. If\nthe ref is behind the default branch for the repository, we will attempt to merge it for you. If the merge succeeds,\nthe API will return a successful merge commit. If merge conflicts prevent the merge from succeeding, the API will\nreturn a failure response.
By default, commit statuses for every submitted context must be in a success\nstate. The required_contexts parameter allows you to specify a subset of contexts that must be success, or to\nspecify contexts that have not yet been submitted. You are not required to use commit statuses to deploy. If you do\nnot require any contexts or create any commit statuses, the deployment will always succeed.
The payload parameter is available for any extra information that a deployment system might need. It is a JSON text\nfield that will be passed on when a deployment event is dispatched.
The task parameter is used by the deployment system to allow different execution paths. In the web world this might\nbe deploy:migrations to run schema changes on the system. In the compiled world this could be a flag to compile an\napplication with debugging enabled.
Users with repo or repo_deployment scopes can create a deployment for a given ref.
You will see this response when GitHub automatically merges the base branch into the topic branch instead of creating\na deployment. This auto-merge happens when:
\nmaster in the response exampleIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.
\nThis error happens when the auto_merge option is enabled and when the default branch (in this case master), can't\nbe merged into the branch that's being deployed (in this case topic-branch), due to merge conflicts.
This error happens when the required_contexts parameter indicates that one or more contexts need to have a success\nstatus for the commit to be deployed, but one or more of the required contexts do not have a state of success.
Deployments offer a few configurable parameters with certain defaults.
\nThe ref parameter can be any named branch, tag, or SHA. At GitHub Enterprise Server we often deploy branches and verify them\nbefore we merge a pull request.
The environment parameter allows deployments to be issued to different runtime environments. Teams often have\nmultiple environments for verifying their applications, such as production, staging, and qa. This parameter\nmakes it easier to track which environments have requested deployments. The default environment is production.
The auto_merge parameter is used to ensure that the requested ref is not behind the repository's default branch. If\nthe ref is behind the default branch for the repository, we will attempt to merge it for you. If the merge succeeds,\nthe API will return a successful merge commit. If merge conflicts prevent the merge from succeeding, the API will\nreturn a failure response.
By default, commit statuses for every submitted context must be in a success\nstate. The required_contexts parameter allows you to specify a subset of contexts that must be success, or to\nspecify contexts that have not yet been submitted. You are not required to use commit statuses to deploy. If you do\nnot require any contexts or create any commit statuses, the deployment will always succeed.
The payload parameter is available for any extra information that a deployment system might need. It is a JSON text\nfield that will be passed on when a deployment event is dispatched.
The task parameter is used by the deployment system to allow different execution paths. In the web world this might\nbe deploy:migrations to run schema changes on the system. In the compiled world this could be a flag to compile an\napplication with debugging enabled.
Users with repo or repo_deployment scopes can create a deployment for a given ref.
Merged branch response:
\nYou will see this response when GitHub automatically merges the base branch into the topic branch instead of creating\na deployment. This auto-merge happens when:
\nmaster in the response exampleIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.
\nMerge conflict response:
\nThis error happens when the auto_merge option is enabled and when the default branch (in this case master), can't\nbe merged into the branch that's being deployed (in this case topic-branch), due to merge conflicts.
Failed commit status checks:
\nThis error happens when the required_contexts parameter indicates that one or more contexts need to have a success\nstatus for the commit to be deployed, but one or more of the required contexts do not have a state of success.
Gets the contents of a file or directory in a repository. Specify the file path or directory in :path. If you omit\n:path, you will receive the contents of the repository's root directory. See the description below regarding what the API response includes for directories.
Files and symlinks support a custom media type for\nretrieving the raw content or rendered HTML (when supported). All content types support a custom media\ntype to ensure the content is returned in a consistent\nobject format.
\nNotes:
\nIf the requested file's size is:
\nraw or object custom media types are supported. Both will work as normal, except that when using the object media type, the content field will be an empty string and the encoding field will be \"none\". To get the contents of these larger files, use the raw media type.The response will be an array of objects, one object for each item in the directory.\nWhen listing the contents of a directory, submodules have their \"type\" specified as \"file\". Logically, the value\nshould be \"submodule\". This behavior exists in API v3 for backwards compatibility purposes.\nIn the next major version of the API, the type will be returned as \"submodule\".
\nIf the requested :path points to a symlink, and the symlink's target is a normal file in the repository, then the\nAPI responds with the content of the file (in the format shown in the example. Otherwise, the API responds with an object\ndescribing the symlink itself.
The submodule_git_url identifies the location of the submodule repository, and the sha identifies a specific\ncommit within the submodule repository. Git uses the given URL when cloning the submodule repository, and checks out\nthe submodule at that specific commit.
If the submodule repository is not hosted on github.com, the Git URLs (git_url and _links[\"git\"]) and the\ngithub.com URLs (html_url and _links[\"html\"]) will have null values.
Gets the contents of a file or directory in a repository. Specify the file path or directory in :path. If you omit\n:path, you will receive the contents of the repository's root directory. See the description below regarding what the API response includes for directories.
Files and symlinks support a custom media type for\nretrieving the raw content or rendered HTML (when supported). All content types support a custom media\ntype to ensure the content is returned in a consistent\nobject format.
\nNotes:
\nTo get a repository's contents recursively, you can recursively get the tree.
\nThis API has an upper limit of 1,000 files for a directory. If you need to retrieve more files, use the Git Trees\nAPI.
\nDownload URLs expire and are meant to be used just once. To ensure the download URL does not expire, please use the contents API to obtain a fresh download URL for each download.\nSize limits:\nIf the requested file's size is:
\n1 MB or smaller: All features of this endpoint are supported.
\nBetween 1-100 MB: Only the raw or object custom media types are supported. Both will work as normal, except that when using the object media type, the content field will be an empty string and the encoding field will be \"none\". To get the contents of these larger files, use the raw media type.
Greater than 100 MB: This endpoint is not supported.
\nIf the content is a directory:\nThe response will be an array of objects, one object for each item in the directory.\nWhen listing the contents of a directory, submodules have their \"type\" specified as \"file\". Logically, the value\nshould be \"submodule\". This behavior exists in API v3 for backwards compatibility purposes.\nIn the next major version of the API, the type will be returned as \"submodule\".
\n If the content is a symlink:\nIf the requested :path points to a symlink, and the symlink's target is a normal file in the repository, then the\nAPI responds with the content of the file (in the format shown in the example. Otherwise, the API responds with an object\ndescribing the symlink itself.
If the content is a submodule:\nThe submodule_git_url identifies the location of the submodule repository, and the sha identifies a specific\ncommit within the submodule repository. Git uses the given URL when cloning the submodule repository, and checks out\nthe submodule at that specific commit.
If the submodule repository is not hosted on github.com, the Git URLs (git_url and _links[\"git\"]) and the\ngithub.com URLs (html_url and _links[\"html\"]) will have null values.
Searches for query terms inside of a file. This method returns up to 100 results per page.
\nWhen searching for code, you can get text match metadata for the file content and file path fields when you pass the text-match media type. For more details about how to receive highlighted search results, see Text match metadata.
For example, if you want to find the definition of the addClass function inside jQuery repository, your query would look something like this:
q=addClass+in:file+language:js+repo:jquery/jquery
This query searches for the keyword addClass within a file's contents. The query limits the search to files where the language is JavaScript in the jquery/jquery repository.
Due to the complexity of searching code, there are a few restrictions on how searches are performed:
\nmaster branch.language:go is not valid, while amazing language:go is.Searches for query terms inside of a file. This method returns up to 100 results per page.
\nWhen searching for code, you can get text match metadata for the file content and file path fields when you pass the text-match media type. For more details about how to receive highlighted search results, see Text match metadata.
For example, if you want to find the definition of the addClass function inside jQuery repository, your query would look something like this:
q=addClass+in:file+language:js+repo:jquery/jquery
This query searches for the keyword addClass within a file's contents. The query limits the search to files where the language is JavaScript in the jquery/jquery repository.
Considerations for code search:
\nDue to the complexity of searching code, there are a few restrictions on how searches are performed:
\nmaster branch.language:go is not valid, while amazing language:go is.A comment on an issue or pull request was created.
", - "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" or \"Pull requests\" repository permissions.
", + "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" repository permission.
", "bodyParameters": [ { "type": "string", @@ -43615,7 +43615,7 @@ }, "deleted": { "descriptionHtml": "A comment on an issue or pull request was deleted.
", - "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" or \"Pull requests\" repository permissions.
", + "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" repository permission.
", "bodyParameters": [ { "type": "string", @@ -44201,7 +44201,7 @@ }, "edited": { "descriptionHtml": "A comment on an issue or pull request was edited.
", - "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" or \"Pull requests\" repository permissions.
", + "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" repository permission.
", "bodyParameters": [ { "type": "string", diff --git a/src/webhooks/data/ghae/schema.json b/src/webhooks/data/ghae/schema.json index 4e3f01143b..52ead4501b 100644 --- a/src/webhooks/data/ghae/schema.json +++ b/src/webhooks/data/ghae/schema.json @@ -41787,7 +41787,7 @@ "issue_comment": { "created": { "descriptionHtml": "A comment on an issue or pull request was created.
", - "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" or \"Pull requests\" repository permissions.
", + "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" repository permission.
", "bodyParameters": [ { "type": "string", @@ -42372,7 +42372,7 @@ }, "deleted": { "descriptionHtml": "A comment on an issue or pull request was deleted.
", - "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" or \"Pull requests\" repository permissions.
", + "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" repository permission.
", "bodyParameters": [ { "type": "string", @@ -42958,7 +42958,7 @@ }, "edited": { "descriptionHtml": "A comment on an issue or pull request was edited.
", - "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" or \"Pull requests\" repository permissions.
", + "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" repository permission.
", "bodyParameters": [ { "type": "string", diff --git a/src/webhooks/data/ghec/schema.json b/src/webhooks/data/ghec/schema.json index 7c1df8f1a5..07b4036ba2 100644 --- a/src/webhooks/data/ghec/schema.json +++ b/src/webhooks/data/ghec/schema.json @@ -43030,7 +43030,7 @@ "issue_comment": { "created": { "descriptionHtml": "A comment on an issue or pull request was created.
", - "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" or \"Pull requests\" repository permissions.
", + "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" repository permission.
", "bodyParameters": [ { "type": "string", @@ -43615,7 +43615,7 @@ }, "deleted": { "descriptionHtml": "A comment on an issue or pull request was deleted.
", - "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" or \"Pull requests\" repository permissions.
", + "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" repository permission.
", "bodyParameters": [ { "type": "string", @@ -44201,7 +44201,7 @@ }, "edited": { "descriptionHtml": "A comment on an issue or pull request was edited.
", - "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" or \"Pull requests\" repository permissions.
", + "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" repository permission.
", "bodyParameters": [ { "type": "string", diff --git a/src/webhooks/data/ghes-3.7/schema.json b/src/webhooks/data/ghes-3.7/schema.json index 6635cd55ad..54bd246509 100644 --- a/src/webhooks/data/ghes-3.7/schema.json +++ b/src/webhooks/data/ghes-3.7/schema.json @@ -36811,7 +36811,7 @@ "issue_comment": { "created": { "descriptionHtml": "A comment on an issue or pull request was created.
", - "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" or \"Pull requests\" repository permissions.
", + "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" repository permission.
", "bodyParameters": [ { "type": "string", @@ -37396,7 +37396,7 @@ }, "deleted": { "descriptionHtml": "A comment on an issue or pull request was deleted.
", - "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" or \"Pull requests\" repository permissions.
", + "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" repository permission.
", "bodyParameters": [ { "type": "string", @@ -37982,7 +37982,7 @@ }, "edited": { "descriptionHtml": "A comment on an issue or pull request was edited.
", - "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" or \"Pull requests\" repository permissions.
", + "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" repository permission.
", "bodyParameters": [ { "type": "string", diff --git a/src/webhooks/data/ghes-3.8/schema.json b/src/webhooks/data/ghes-3.8/schema.json index e396f47c77..74369dd036 100644 --- a/src/webhooks/data/ghes-3.8/schema.json +++ b/src/webhooks/data/ghes-3.8/schema.json @@ -36811,7 +36811,7 @@ "issue_comment": { "created": { "descriptionHtml": "A comment on an issue or pull request was created.
", - "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" or \"Pull requests\" repository permissions.
", + "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" repository permission.
", "bodyParameters": [ { "type": "string", @@ -37396,7 +37396,7 @@ }, "deleted": { "descriptionHtml": "A comment on an issue or pull request was deleted.
", - "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" or \"Pull requests\" repository permissions.
", + "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" repository permission.
", "bodyParameters": [ { "type": "string", @@ -37982,7 +37982,7 @@ }, "edited": { "descriptionHtml": "A comment on an issue or pull request was edited.
", - "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" or \"Pull requests\" repository permissions.
", + "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" repository permission.
", "bodyParameters": [ { "type": "string", diff --git a/src/webhooks/data/ghes-3.9/schema.json b/src/webhooks/data/ghes-3.9/schema.json index 6c11edf388..1ad1c4863b 100644 --- a/src/webhooks/data/ghes-3.9/schema.json +++ b/src/webhooks/data/ghes-3.9/schema.json @@ -38181,7 +38181,7 @@ "issue_comment": { "created": { "descriptionHtml": "A comment on an issue or pull request was created.
", - "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" or \"Pull requests\" repository permissions.
", + "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" repository permission.
", "bodyParameters": [ { "type": "string", @@ -38766,7 +38766,7 @@ }, "deleted": { "descriptionHtml": "A comment on an issue or pull request was deleted.
", - "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" or \"Pull requests\" repository permissions.
", + "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" repository permission.
", "bodyParameters": [ { "type": "string", @@ -39352,7 +39352,7 @@ }, "edited": { "descriptionHtml": "A comment on an issue or pull request was edited.
", - "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" or \"Pull requests\" repository permissions.
", + "summaryHtml": "This event occurs when there is activity relating to a comment on an issue or pull request. For more information about issues and pull requests, see \"About issues\" and \"About pull requests.\" For information about the APIs to manage issue comments, see the GraphQL documentation or \"Issue comments\" in the REST API documentation.
\nFor activity relating to an issue as opposed to comments on an issue, use the issue event. For activity related to pull request reviews or pull request review comments, use the pull_request_review or pull_request_review_comment events. For more information about the different types of pull request comments, see \"Working with comments.\"
To subscribe to this event, a GitHub App must have at least read-level access for the \"Issues\" repository permission.
", "bodyParameters": [ { "type": "string", diff --git a/src/webhooks/lib/config.json b/src/webhooks/lib/config.json index 9a9b6604ef..afc486647d 100644 --- a/src/webhooks/lib/config.json +++ b/src/webhooks/lib/config.json @@ -1,3 +1,3 @@ { - "sha": "077cc2ca0a2b337f0314c5576e09bab4f247deb1" + "sha": "19833171fa53a9a674f247f795f0cf44a65a05e4" } \ No newline at end of file