Merge pull request #23569 from github/openapi-update-2bb36b41f26d446f92cddb1bfbcfc99b4bb6bc3c05f3aca0eb23476d37598b33
Update OpenAPI Descriptions
This commit is contained in:
Sarita Iyer
@@ -9798,7 +9798,7 @@
|
||||
},
|
||||
"x-github": {
|
||||
"githubCloudOnly": false,
|
||||
"enabledForGitHubApps": true,
|
||||
"enabledForGitHubApps": false,
|
||||
"previews": [],
|
||||
"category": "enterprise-admin",
|
||||
"subcategory": "billing"
|
||||
@@ -50201,7 +50201,7 @@
|
||||
}
|
||||
],
|
||||
"summary": "Update a code scanning alert",
|
||||
"description": "Updates the status of a single code scanning alert. You must use an access token with the `security_events` scope to use this endpoint. GitHub Apps must have the `security_events` write permission to use this endpoint.",
|
||||
"description": "Updates the status of a single code scanning alert. You must use an access token with the `security_events` scope to use this endpoint with private repositories. You can also use tokens with the `public_repo` scope for public repositories only. GitHub Apps must have the `security_events` write permission to use this endpoint.",
|
||||
"operationId": "code-scanning/update-alert",
|
||||
"tags": [
|
||||
"code-scanning"
|
||||
@@ -50268,7 +50268,7 @@
|
||||
"categoryLabel": "Code scanning",
|
||||
"contentType": "application/json",
|
||||
"notes": [],
|
||||
"descriptionHTML": "<p>Updates the status of a single code scanning alert. You must use an access token with the <code>security_events</code> scope to use this endpoint. GitHub Apps must have the <code>security_events</code> write permission to use this endpoint.</p>",
|
||||
"descriptionHTML": "<p>Updates the status of a single code scanning alert. You must use an access token with the <code>security_events</code> scope to use this endpoint with private repositories. You can also use tokens with the <code>public_repo</code> scope for public repositories only. GitHub Apps must have the <code>security_events</code> write permission to use this endpoint.</p>",
|
||||
"bodyParameters": [
|
||||
{
|
||||
"description": "<p><strong>Required</strong>. Sets the state of the code scanning alert. Can be one of <code>open</code> or <code>dismissed</code>. You must provide <code>dismissed_reason</code> when you set the state to <code>dismissed</code>.</p>",
|
||||
@@ -50745,7 +50745,7 @@
|
||||
}
|
||||
],
|
||||
"summary": "Delete a code scanning analysis from a repository",
|
||||
"description": "Deletes a specified code scanning analysis from a repository. For\nprivate repositories, you must use an access token with the `repo` scope. For public repositories,\nyou must use an access token with `public_repo` and `repo:security_events` scopes.\nGitHub Apps must have the `security_events` write permission to use this endpoint.\n\nYou can delete one analysis at a time.\nTo delete a series of analyses, start with the most recent analysis and work backwards.\nConceptually, the process is similar to the undo function in a text editor.\n\nWhen you list the analyses for a repository,\none or more will be identified as deletable in the response:\n\n```\n\"deletable\": true\n```\n\nAn analysis is deletable when it's the most recent in a set of analyses.\nTypically, a repository will have multiple sets of analyses\nfor each enabled code scanning tool,\nwhere a set is determined by a unique combination of analysis values:\n\n* `ref`\n* `tool`\n* `analysis_key`\n* `environment`\n\nIf you attempt to delete an analysis that is not the most recent in a set,\nyou'll get a 400 response with the message:\n\n```\nAnalysis specified is not deletable.\n```\n\nThe response from a successful `DELETE` operation provides you with\ntwo alternative URLs for deleting the next analysis in the set:\n`next_analysis_url` and `confirm_delete_url`.\nUse the `next_analysis_url` URL if you want to avoid accidentally deleting the final analysis\nin a set. This is a useful option if you want to preserve at least one analysis\nfor the specified tool in your repository.\nUse the `confirm_delete_url` URL if you are content to remove all analyses for a tool.\nWhen you delete the last analysis in a set, the value of `next_analysis_url` and `confirm_delete_url`\nin the 200 response is `null`.\n\nAs an example of the deletion process,\nlet's imagine that you added a workflow that configured a particular code scanning tool\nto analyze the code in a repository. This tool has added 15 analyses:\n10 on the default branch, and another 5 on a topic branch.\nYou therefore have two separate sets of analyses for this tool.\nYou've now decided that you want to remove all of the analyses for the tool.\nTo do this you must make 15 separate deletion requests.\nTo start, you must find an analysis that's identified as deletable.\nEach set of analyses always has one that's identified as deletable.\nHaving found the deletable analysis for one of the two sets,\ndelete this analysis and then continue deleting the next analysis in the set until they're all deleted.\nThen repeat the process for the second set.\nThe procedure therefore consists of a nested loop:\n\n**Outer loop**:\n* List the analyses for the repository, filtered by tool.\n* Parse this list to find a deletable analysis. If found:\n\n **Inner loop**:\n * Delete the identified analysis.\n * Parse the response for the value of `confirm_delete_url` and, if found, use this in the next iteration.\n\nThe above process assumes that you want to remove all trace of the tool's analyses from the GitHub user interface, for the specified repository, and it therefore uses the `confirm_delete_url` value. Alternatively, you could use the `next_analysis_url` value, which would leave the last analysis in each set undeleted to avoid removing a tool's analysis entirely.",
|
||||
"description": "Deletes a specified code scanning analysis from a repository. For\nprivate repositories, you must use an access token with the `repo` scope. For public repositories,\nyou must use an access token with `public_repo` scope.\nGitHub Apps must have the `security_events` write permission to use this endpoint.\n\nYou can delete one analysis at a time.\nTo delete a series of analyses, start with the most recent analysis and work backwards.\nConceptually, the process is similar to the undo function in a text editor.\n\nWhen you list the analyses for a repository,\none or more will be identified as deletable in the response:\n\n```\n\"deletable\": true\n```\n\nAn analysis is deletable when it's the most recent in a set of analyses.\nTypically, a repository will have multiple sets of analyses\nfor each enabled code scanning tool,\nwhere a set is determined by a unique combination of analysis values:\n\n* `ref`\n* `tool`\n* `analysis_key`\n* `environment`\n\nIf you attempt to delete an analysis that is not the most recent in a set,\nyou'll get a 400 response with the message:\n\n```\nAnalysis specified is not deletable.\n```\n\nThe response from a successful `DELETE` operation provides you with\ntwo alternative URLs for deleting the next analysis in the set:\n`next_analysis_url` and `confirm_delete_url`.\nUse the `next_analysis_url` URL if you want to avoid accidentally deleting the final analysis\nin a set. This is a useful option if you want to preserve at least one analysis\nfor the specified tool in your repository.\nUse the `confirm_delete_url` URL if you are content to remove all analyses for a tool.\nWhen you delete the last analysis in a set, the value of `next_analysis_url` and `confirm_delete_url`\nin the 200 response is `null`.\n\nAs an example of the deletion process,\nlet's imagine that you added a workflow that configured a particular code scanning tool\nto analyze the code in a repository. This tool has added 15 analyses:\n10 on the default branch, and another 5 on a topic branch.\nYou therefore have two separate sets of analyses for this tool.\nYou've now decided that you want to remove all of the analyses for the tool.\nTo do this you must make 15 separate deletion requests.\nTo start, you must find an analysis that's identified as deletable.\nEach set of analyses always has one that's identified as deletable.\nHaving found the deletable analysis for one of the two sets,\ndelete this analysis and then continue deleting the next analysis in the set until they're all deleted.\nThen repeat the process for the second set.\nThe procedure therefore consists of a nested loop:\n\n**Outer loop**:\n* List the analyses for the repository, filtered by tool.\n* Parse this list to find a deletable analysis. If found:\n\n **Inner loop**:\n * Delete the identified analysis.\n * Parse the response for the value of `confirm_delete_url` and, if found, use this in the next iteration.\n\nThe above process assumes that you want to remove all trace of the tool's analyses from the GitHub user interface, for the specified repository, and it therefore uses the `confirm_delete_url` value. Alternatively, you could use the `next_analysis_url` value, which would leave the last analysis in each set undeleted to avoid removing a tool's analysis entirely.",
|
||||
"operationId": "code-scanning/delete-analysis",
|
||||
"tags": [
|
||||
"code-scanning"
|
||||
@@ -50764,7 +50764,7 @@
|
||||
"categoryLabel": "Code scanning",
|
||||
"notes": [],
|
||||
"bodyParameters": [],
|
||||
"descriptionHTML": "<p>Deletes a specified code scanning analysis from a repository. For\nprivate repositories, you must use an access token with the <code>repo</code> scope. For public repositories,\nyou must use an access token with <code>public_repo</code> and <code>repo:security_events</code> scopes.\nGitHub Apps must have the <code>security_events</code> write permission to use this endpoint.</p>\n<p>You can delete one analysis at a time.\nTo delete a series of analyses, start with the most recent analysis and work backwards.\nConceptually, the process is similar to the undo function in a text editor.</p>\n<p>When you list the analyses for a repository,\none or more will be identified as deletable in the response:</p>\n<pre><code>\"deletable\": true\n</code></pre>\n<p>An analysis is deletable when it's the most recent in a set of analyses.\nTypically, a repository will have multiple sets of analyses\nfor each enabled code scanning tool,\nwhere a set is determined by a unique combination of analysis values:</p>\n<ul>\n<li><code>ref</code></li>\n<li><code>tool</code></li>\n<li><code>analysis_key</code></li>\n<li><code>environment</code></li>\n</ul>\n<p>If you attempt to delete an analysis that is not the most recent in a set,\nyou'll get a 400 response with the message:</p>\n<pre><code>Analysis specified is not deletable.\n</code></pre>\n<p>The response from a successful <code>DELETE</code> operation provides you with\ntwo alternative URLs for deleting the next analysis in the set:\n<code>next_analysis_url</code> and <code>confirm_delete_url</code>.\nUse the <code>next_analysis_url</code> URL if you want to avoid accidentally deleting the final analysis\nin a set. This is a useful option if you want to preserve at least one analysis\nfor the specified tool in your repository.\nUse the <code>confirm_delete_url</code> URL if you are content to remove all analyses for a tool.\nWhen you delete the last analysis in a set, the value of <code>next_analysis_url</code> and <code>confirm_delete_url</code>\nin the 200 response is <code>null</code>.</p>\n<p>As an example of the deletion process,\nlet's imagine that you added a workflow that configured a particular code scanning tool\nto analyze the code in a repository. This tool has added 15 analyses:\n10 on the default branch, and another 5 on a topic branch.\nYou therefore have two separate sets of analyses for this tool.\nYou've now decided that you want to remove all of the analyses for the tool.\nTo do this you must make 15 separate deletion requests.\nTo start, you must find an analysis that's identified as deletable.\nEach set of analyses always has one that's identified as deletable.\nHaving found the deletable analysis for one of the two sets,\ndelete this analysis and then continue deleting the next analysis in the set until they're all deleted.\nThen repeat the process for the second set.\nThe procedure therefore consists of a nested loop:</p>\n<p><strong>Outer loop</strong>:</p>\n<ul>\n<li>\n<p>List the analyses for the repository, filtered by tool.</p>\n</li>\n<li>\n<p>Parse this list to find a deletable analysis. If found:</p>\n<p><strong>Inner loop</strong>:</p>\n<ul>\n<li>Delete the identified analysis.</li>\n<li>Parse the response for the value of <code>confirm_delete_url</code> and, if found, use this in the next iteration.</li>\n</ul>\n</li>\n</ul>\n<p>The above process assumes that you want to remove all trace of the tool's analyses from the GitHub user interface, for the specified repository, and it therefore uses the <code>confirm_delete_url</code> value. Alternatively, you could use the <code>next_analysis_url</code> value, which would leave the last analysis in each set undeleted to avoid removing a tool's analysis entirely.</p>",
|
||||
"descriptionHTML": "<p>Deletes a specified code scanning analysis from a repository. For\nprivate repositories, you must use an access token with the <code>repo</code> scope. For public repositories,\nyou must use an access token with <code>public_repo</code> scope.\nGitHub Apps must have the <code>security_events</code> write permission to use this endpoint.</p>\n<p>You can delete one analysis at a time.\nTo delete a series of analyses, start with the most recent analysis and work backwards.\nConceptually, the process is similar to the undo function in a text editor.</p>\n<p>When you list the analyses for a repository,\none or more will be identified as deletable in the response:</p>\n<pre><code>\"deletable\": true\n</code></pre>\n<p>An analysis is deletable when it's the most recent in a set of analyses.\nTypically, a repository will have multiple sets of analyses\nfor each enabled code scanning tool,\nwhere a set is determined by a unique combination of analysis values:</p>\n<ul>\n<li><code>ref</code></li>\n<li><code>tool</code></li>\n<li><code>analysis_key</code></li>\n<li><code>environment</code></li>\n</ul>\n<p>If you attempt to delete an analysis that is not the most recent in a set,\nyou'll get a 400 response with the message:</p>\n<pre><code>Analysis specified is not deletable.\n</code></pre>\n<p>The response from a successful <code>DELETE</code> operation provides you with\ntwo alternative URLs for deleting the next analysis in the set:\n<code>next_analysis_url</code> and <code>confirm_delete_url</code>.\nUse the <code>next_analysis_url</code> URL if you want to avoid accidentally deleting the final analysis\nin a set. This is a useful option if you want to preserve at least one analysis\nfor the specified tool in your repository.\nUse the <code>confirm_delete_url</code> URL if you are content to remove all analyses for a tool.\nWhen you delete the last analysis in a set, the value of <code>next_analysis_url</code> and <code>confirm_delete_url</code>\nin the 200 response is <code>null</code>.</p>\n<p>As an example of the deletion process,\nlet's imagine that you added a workflow that configured a particular code scanning tool\nto analyze the code in a repository. This tool has added 15 analyses:\n10 on the default branch, and another 5 on a topic branch.\nYou therefore have two separate sets of analyses for this tool.\nYou've now decided that you want to remove all of the analyses for the tool.\nTo do this you must make 15 separate deletion requests.\nTo start, you must find an analysis that's identified as deletable.\nEach set of analyses always has one that's identified as deletable.\nHaving found the deletable analysis for one of the two sets,\ndelete this analysis and then continue deleting the next analysis in the set until they're all deleted.\nThen repeat the process for the second set.\nThe procedure therefore consists of a nested loop:</p>\n<p><strong>Outer loop</strong>:</p>\n<ul>\n<li>\n<p>List the analyses for the repository, filtered by tool.</p>\n</li>\n<li>\n<p>Parse this list to find a deletable analysis. If found:</p>\n<p><strong>Inner loop</strong>:</p>\n<ul>\n<li>Delete the identified analysis.</li>\n<li>Parse the response for the value of <code>confirm_delete_url</code> and, if found, use this in the next iteration.</li>\n</ul>\n</li>\n</ul>\n<p>The above process assumes that you want to remove all trace of the tool's analyses from the GitHub user interface, for the specified repository, and it therefore uses the <code>confirm_delete_url</code> value. Alternatively, you could use the <code>next_analysis_url</code> value, which would leave the last analysis in each set undeleted to avoid removing a tool's analysis entirely.</p>",
|
||||
"responses": [
|
||||
{
|
||||
"httpStatusCode": "200",
|
||||
@@ -50831,7 +50831,7 @@
|
||||
}
|
||||
],
|
||||
"summary": "Upload an analysis as SARIF data",
|
||||
"description": "Uploads SARIF data containing the results of a code scanning analysis to make the results available in a repository. You must use an access token with the `security_events` scope to use this endpoint. GitHub Apps must have the `security_events` write permission to use this endpoint.\n\nThere are two places where you can upload code scanning results.\n - If you upload to a pull request, for example `--ref refs/pull/42/merge` or `--ref refs/pull/42/head`, then the results appear as alerts in a pull request check. For more information, see \"[Triaging code scanning alerts in pull requests](/code-security/secure-coding/triaging-code-scanning-alerts-in-pull-requests).\"\n - If you upload to a branch, for example `--ref refs/heads/my-branch`, then the results appear in the **Security** tab for your repository. For more information, see \"[Managing code scanning alerts for your repository](/code-security/secure-coding/managing-code-scanning-alerts-for-your-repository#viewing-the-alerts-for-a-repository).\"\n\nYou must compress the SARIF-formatted analysis data that you want to upload, using `gzip`, and then encode it as a Base64 format string. For example:\n\n```\ngzip -c analysis-data.sarif | base64 -w0\n```\n\nSARIF upload supports a maximum of 5000 results per analysis run. Any results over this limit are ignored and any SARIF uploads with more than 25,000 results are rejected. Typically, but not necessarily, a SARIF file contains a single run of a single tool. If a code scanning tool generates too many results, you should update the analysis configuration to run only the most important rules or queries.\n\nThe `202 Accepted`, response includes an `id` value.\nYou can use this ID to check the status of the upload by using this for the `/sarifs/{sarif_id}` endpoint.\nFor more information, see \"[Get information about a SARIF upload](/rest/reference/code-scanning#get-information-about-a-sarif-upload).\"",
|
||||
"description": "Uploads SARIF data containing the results of a code scanning analysis to make the results available in a repository. You must use an access token with the `security_events` scope to use this endpoint for private repositories. You can also use tokens with the `public_repo` scope for public repositories only. GitHub Apps must have the `security_events` write permission to use this endpoint.\n\nThere are two places where you can upload code scanning results.\n - If you upload to a pull request, for example `--ref refs/pull/42/merge` or `--ref refs/pull/42/head`, then the results appear as alerts in a pull request check. For more information, see \"[Triaging code scanning alerts in pull requests](/code-security/secure-coding/triaging-code-scanning-alerts-in-pull-requests).\"\n - If you upload to a branch, for example `--ref refs/heads/my-branch`, then the results appear in the **Security** tab for your repository. For more information, see \"[Managing code scanning alerts for your repository](/code-security/secure-coding/managing-code-scanning-alerts-for-your-repository#viewing-the-alerts-for-a-repository).\"\n\nYou must compress the SARIF-formatted analysis data that you want to upload, using `gzip`, and then encode it as a Base64 format string. For example:\n\n```\ngzip -c analysis-data.sarif | base64 -w0\n```\n\nSARIF upload supports a maximum of 5000 results per analysis run. Any results over this limit are ignored and any SARIF uploads with more than 25,000 results are rejected. Typically, but not necessarily, a SARIF file contains a single run of a single tool. If a code scanning tool generates too many results, you should update the analysis configuration to run only the most important rules or queries.\n\nThe `202 Accepted`, response includes an `id` value.\nYou can use this ID to check the status of the upload by using this for the `/sarifs/{sarif_id}` endpoint.\nFor more information, see \"[Get information about a SARIF upload](/rest/reference/code-scanning#get-information-about-a-sarif-upload).\"",
|
||||
"operationId": "code-scanning/upload-sarif",
|
||||
"tags": [
|
||||
"code-scanning"
|
||||
@@ -50927,7 +50927,7 @@
|
||||
"categoryLabel": "Code scanning",
|
||||
"contentType": "application/json",
|
||||
"notes": [],
|
||||
"descriptionHTML": "<p>Uploads SARIF data containing the results of a code scanning analysis to make the results available in a repository. You must use an access token with the <code>security_events</code> scope to use this endpoint. GitHub Apps must have the <code>security_events</code> write permission to use this endpoint.</p>\n<p>There are two places where you can upload code scanning results.</p>\n<ul>\n<li>If you upload to a pull request, for example <code>--ref refs/pull/42/merge</code> or <code>--ref refs/pull/42/head</code>, then the results appear as alerts in a pull request check. For more information, see \"<a href=\"/code-security/secure-coding/triaging-code-scanning-alerts-in-pull-requests\">Triaging code scanning alerts in pull requests</a>.\"</li>\n<li>If you upload to a branch, for example <code>--ref refs/heads/my-branch</code>, then the results appear in the <strong>Security</strong> tab for your repository. For more information, see \"<a href=\"/code-security/secure-coding/managing-code-scanning-alerts-for-your-repository#viewing-the-alerts-for-a-repository\">Managing code scanning alerts for your repository</a>.\"</li>\n</ul>\n<p>You must compress the SARIF-formatted analysis data that you want to upload, using <code>gzip</code>, and then encode it as a Base64 format string. For example:</p>\n<pre><code>gzip -c analysis-data.sarif | base64 -w0\n</code></pre>\n<p>SARIF upload supports a maximum of 5000 results per analysis run. Any results over this limit are ignored and any SARIF uploads with more than 25,000 results are rejected. Typically, but not necessarily, a SARIF file contains a single run of a single tool. If a code scanning tool generates too many results, you should update the analysis configuration to run only the most important rules or queries.</p>\n<p>The <code>202 Accepted</code>, response includes an <code>id</code> value.\nYou can use this ID to check the status of the upload by using this for the <code>/sarifs/{sarif_id}</code> endpoint.\nFor more information, see \"<a href=\"/rest/reference/code-scanning#get-information-about-a-sarif-upload\">Get information about a SARIF upload</a>.\"</p>",
|
||||
"descriptionHTML": "<p>Uploads SARIF data containing the results of a code scanning analysis to make the results available in a repository. You must use an access token with the <code>security_events</code> scope to use this endpoint for private repositories. You can also use tokens with the <code>public_repo</code> scope for public repositories only. GitHub Apps must have the <code>security_events</code> write permission to use this endpoint.</p>\n<p>There are two places where you can upload code scanning results.</p>\n<ul>\n<li>If you upload to a pull request, for example <code>--ref refs/pull/42/merge</code> or <code>--ref refs/pull/42/head</code>, then the results appear as alerts in a pull request check. For more information, see \"<a href=\"/code-security/secure-coding/triaging-code-scanning-alerts-in-pull-requests\">Triaging code scanning alerts in pull requests</a>.\"</li>\n<li>If you upload to a branch, for example <code>--ref refs/heads/my-branch</code>, then the results appear in the <strong>Security</strong> tab for your repository. For more information, see \"<a href=\"/code-security/secure-coding/managing-code-scanning-alerts-for-your-repository#viewing-the-alerts-for-a-repository\">Managing code scanning alerts for your repository</a>.\"</li>\n</ul>\n<p>You must compress the SARIF-formatted analysis data that you want to upload, using <code>gzip</code>, and then encode it as a Base64 format string. For example:</p>\n<pre><code>gzip -c analysis-data.sarif | base64 -w0\n</code></pre>\n<p>SARIF upload supports a maximum of 5000 results per analysis run. Any results over this limit are ignored and any SARIF uploads with more than 25,000 results are rejected. Typically, but not necessarily, a SARIF file contains a single run of a single tool. If a code scanning tool generates too many results, you should update the analysis configuration to run only the most important rules or queries.</p>\n<p>The <code>202 Accepted</code>, response includes an <code>id</code> value.\nYou can use this ID to check the status of the upload by using this for the <code>/sarifs/{sarif_id}</code> endpoint.\nFor more information, see \"<a href=\"/rest/reference/code-scanning#get-information-about-a-sarif-upload\">Get information about a SARIF upload</a>.\"</p>",
|
||||
"bodyParameters": [
|
||||
{
|
||||
"description": "<p><strong>Required</strong>. The SHA of the commit to which the analysis you are uploading relates.</p>",
|
||||
@@ -68394,7 +68394,7 @@
|
||||
}
|
||||
],
|
||||
"summary": "Enable Git LFS for a repository",
|
||||
"description": "**Note:** The Git LFS API endpoints are currently in beta and are subject to change.",
|
||||
"description": "",
|
||||
"operationId": "repos/enable-lfs-for-repo",
|
||||
"tags": [
|
||||
"repos"
|
||||
@@ -68415,6 +68415,7 @@
|
||||
"subcategory": "lfs",
|
||||
"subcategoryLabel": "Lfs",
|
||||
"notes": [],
|
||||
"descriptionHTML": "",
|
||||
"responses": [
|
||||
{
|
||||
"httpStatusCode": "202",
|
||||
@@ -68427,8 +68428,7 @@
|
||||
"description": "We will return a 403 with one of the following messages:\n\n- Git LFS support not enabled because Git LFS is globally disabled.\n- Git LFS support not enabled because Git LFS is disabled for the root repository in the network.\n- Git LFS support not enabled because Git LFS is disabled for <owner>."
|
||||
}
|
||||
],
|
||||
"bodyParameters": [],
|
||||
"descriptionHTML": "<p><strong>Note:</strong> The Git LFS API endpoints are currently in beta and are subject to change.</p>"
|
||||
"bodyParameters": []
|
||||
},
|
||||
{
|
||||
"verb": "delete",
|
||||
@@ -68467,7 +68467,7 @@
|
||||
}
|
||||
],
|
||||
"summary": "Disable Git LFS for a repository",
|
||||
"description": "**Note:** The Git LFS API endpoints are currently in beta and are subject to change.",
|
||||
"description": "",
|
||||
"operationId": "repos/disable-lfs-for-repo",
|
||||
"tags": [
|
||||
"repos"
|
||||
@@ -68488,6 +68488,7 @@
|
||||
"subcategory": "lfs",
|
||||
"subcategoryLabel": "Lfs",
|
||||
"notes": [],
|
||||
"descriptionHTML": "",
|
||||
"responses": [
|
||||
{
|
||||
"httpStatusCode": "204",
|
||||
@@ -68495,8 +68496,7 @@
|
||||
"description": "Response"
|
||||
}
|
||||
],
|
||||
"bodyParameters": [],
|
||||
"descriptionHTML": "<p><strong>Note:</strong> The Git LFS API endpoints are currently in beta and are subject to change.</p>"
|
||||
"bodyParameters": []
|
||||
},
|
||||
{
|
||||
"verb": "get",
|
||||
@@ -68602,7 +68602,7 @@
|
||||
}
|
||||
],
|
||||
"summary": "Sync a fork branch with the upstream repository",
|
||||
"description": "**Note:** This endpoint is currently in beta and subject to change.\n\nSync a branch of a forked repository to keep it up-to-date with the upstream repository.",
|
||||
"description": "Sync a branch of a forked repository to keep it up-to-date with the upstream repository.",
|
||||
"tags": [
|
||||
"repos"
|
||||
],
|
||||
@@ -68651,7 +68651,7 @@
|
||||
"subcategoryLabel": "Branches",
|
||||
"contentType": "application/json",
|
||||
"notes": [],
|
||||
"descriptionHTML": "<p><strong>Note:</strong> This endpoint is currently in beta and subject to change.</p>\n<p>Sync a branch of a forked repository to keep it up-to-date with the upstream repository.</p>",
|
||||
"descriptionHTML": "<p>Sync a branch of a forked repository to keep it up-to-date with the upstream repository.</p>",
|
||||
"bodyParameters": [
|
||||
{
|
||||
"type": "string",
|
||||
|
||||
@@ -64769,7 +64769,7 @@
|
||||
}
|
||||
],
|
||||
"summary": "Enable Git LFS for a repository",
|
||||
"description": "**Note:** The Git LFS API endpoints are currently in beta and are subject to change.",
|
||||
"description": "",
|
||||
"operationId": "repos/enable-lfs-for-repo",
|
||||
"tags": [
|
||||
"repos"
|
||||
@@ -64790,6 +64790,7 @@
|
||||
"subcategory": "lfs",
|
||||
"subcategoryLabel": "Lfs",
|
||||
"notes": [],
|
||||
"descriptionHTML": "",
|
||||
"responses": [
|
||||
{
|
||||
"httpStatusCode": "202",
|
||||
@@ -64802,8 +64803,7 @@
|
||||
"description": "We will return a 403 with one of the following messages:\n\n- Git LFS support not enabled because Git LFS is globally disabled.\n- Git LFS support not enabled because Git LFS is disabled for the root repository in the network.\n- Git LFS support not enabled because Git LFS is disabled for <owner>."
|
||||
}
|
||||
],
|
||||
"bodyParameters": [],
|
||||
"descriptionHTML": "<p><strong>Note:</strong> The Git LFS API endpoints are currently in beta and are subject to change.</p>"
|
||||
"bodyParameters": []
|
||||
},
|
||||
{
|
||||
"verb": "delete",
|
||||
@@ -64842,7 +64842,7 @@
|
||||
}
|
||||
],
|
||||
"summary": "Disable Git LFS for a repository",
|
||||
"description": "**Note:** The Git LFS API endpoints are currently in beta and are subject to change.",
|
||||
"description": "",
|
||||
"operationId": "repos/disable-lfs-for-repo",
|
||||
"tags": [
|
||||
"repos"
|
||||
@@ -64863,6 +64863,7 @@
|
||||
"subcategory": "lfs",
|
||||
"subcategoryLabel": "Lfs",
|
||||
"notes": [],
|
||||
"descriptionHTML": "",
|
||||
"responses": [
|
||||
{
|
||||
"httpStatusCode": "204",
|
||||
@@ -64870,8 +64871,7 @@
|
||||
"description": "Response"
|
||||
}
|
||||
],
|
||||
"bodyParameters": [],
|
||||
"descriptionHTML": "<p><strong>Note:</strong> The Git LFS API endpoints are currently in beta and are subject to change.</p>"
|
||||
"bodyParameters": []
|
||||
},
|
||||
{
|
||||
"verb": "get",
|
||||
@@ -64977,7 +64977,7 @@
|
||||
}
|
||||
],
|
||||
"summary": "Sync a fork branch with the upstream repository",
|
||||
"description": "**Note:** This endpoint is currently in beta and subject to change.\n\nSync a branch of a forked repository to keep it up-to-date with the upstream repository.",
|
||||
"description": "Sync a branch of a forked repository to keep it up-to-date with the upstream repository.",
|
||||
"tags": [
|
||||
"repos"
|
||||
],
|
||||
@@ -65026,7 +65026,7 @@
|
||||
"subcategoryLabel": "Branches",
|
||||
"contentType": "application/json",
|
||||
"notes": [],
|
||||
"descriptionHTML": "<p><strong>Note:</strong> This endpoint is currently in beta and subject to change.</p>\n<p>Sync a branch of a forked repository to keep it up-to-date with the upstream repository.</p>",
|
||||
"descriptionHTML": "<p>Sync a branch of a forked repository to keep it up-to-date with the upstream repository.</p>",
|
||||
"bodyParameters": [
|
||||
{
|
||||
"type": "string",
|
||||
|
||||
@@ -41069,7 +41069,7 @@
|
||||
}
|
||||
],
|
||||
"summary": "Delete a code scanning analysis from a repository",
|
||||
"description": "Deletes a specified code scanning analysis from a repository. For\nprivate repositories, you must use an access token with the `repo` scope. For public repositories,\nyou must use an access token with `public_repo` and `repo:security_events` scopes.\nGitHub Apps must have the `security_events` write permission to use this endpoint.\n\nYou can delete one analysis at a time.\nTo delete a series of analyses, start with the most recent analysis and work backwards.\nConceptually, the process is similar to the undo function in a text editor.\n\nWhen you list the analyses for a repository,\none or more will be identified as deletable in the response:\n\n```\n\"deletable\": true\n```\n\nAn analysis is deletable when it's the most recent in a set of analyses.\nTypically, a repository will have multiple sets of analyses\nfor each enabled code scanning tool,\nwhere a set is determined by a unique combination of analysis values:\n\n* `ref`\n* `tool`\n* `analysis_key`\n* `environment`\n\nIf you attempt to delete an analysis that is not the most recent in a set,\nyou'll get a 400 response with the message:\n\n```\nAnalysis specified is not deletable.\n```\n\nThe response from a successful `DELETE` operation provides you with\ntwo alternative URLs for deleting the next analysis in the set:\n`next_analysis_url` and `confirm_delete_url`.\nUse the `next_analysis_url` URL if you want to avoid accidentally deleting the final analysis\nin a set. This is a useful option if you want to preserve at least one analysis\nfor the specified tool in your repository.\nUse the `confirm_delete_url` URL if you are content to remove all analyses for a tool.\nWhen you delete the last analysis in a set, the value of `next_analysis_url` and `confirm_delete_url`\nin the 200 response is `null`.\n\nAs an example of the deletion process,\nlet's imagine that you added a workflow that configured a particular code scanning tool\nto analyze the code in a repository. This tool has added 15 analyses:\n10 on the default branch, and another 5 on a topic branch.\nYou therefore have two separate sets of analyses for this tool.\nYou've now decided that you want to remove all of the analyses for the tool.\nTo do this you must make 15 separate deletion requests.\nTo start, you must find an analysis that's identified as deletable.\nEach set of analyses always has one that's identified as deletable.\nHaving found the deletable analysis for one of the two sets,\ndelete this analysis and then continue deleting the next analysis in the set until they're all deleted.\nThen repeat the process for the second set.\nThe procedure therefore consists of a nested loop:\n\n**Outer loop**:\n* List the analyses for the repository, filtered by tool.\n* Parse this list to find a deletable analysis. If found:\n\n **Inner loop**:\n * Delete the identified analysis.\n * Parse the response for the value of `confirm_delete_url` and, if found, use this in the next iteration.\n\nThe above process assumes that you want to remove all trace of the tool's analyses from the GitHub user interface, for the specified repository, and it therefore uses the `confirm_delete_url` value. Alternatively, you could use the `next_analysis_url` value, which would leave the last analysis in each set undeleted to avoid removing a tool's analysis entirely.",
|
||||
"description": "Deletes a specified code scanning analysis from a repository. For\nprivate repositories, you must use an access token with the `repo` scope. For public repositories,\nyou must use an access token with `public_repo` and `repo:security_events` scopes.\nGitHub Apps must have the `security_events` write permission to use this endpoint.\n\nYou can delete one analysis at a time.\nTo delete a series of analyses, start with the most recent analysis and work backwards.\nConceptually, the process is similar to the undo function in a text editor.\n\nWhen you list the analyses for a repository,\none or more will be identified as deletable in the response:\n\n```\n\"deletable\": true\n```\n\nAn analysis is deletable when it's the most recent in a set of analyses.\nTypically, a repository will have multiple sets of analyses\nfor each enabled code scanning tool,\nwhere a set is determined by a unique combination of analysis values:\n\n* `ref`\n* `tool`\n* `analysis_key`\n* `environment`\n\nIf you attempt to delete an analysis that is not the most recent in a set,\nyou'll get a 400 response with the message:\n\n```\nAnalysis specified is not deletable.\n```\n\nThe response from a successful `DELETE` operation provides you with\ntwo alternative URLs for deleting the next analysis in the set:\n`next_analysis_url` and `confirm_delete_url`.\nUse the `next_analysis_url` URL if you want to avoid accidentally deleting the final analysis\nin a set. This is a useful option if you want to preserve at least one analysis\nfor the specified tool in your repository.\nUse the `confirm_delete_url` URL if you are content to remove all analyses for a tool.\nWhen you delete the last analysis in a set, the value of `next_analysis_url` and `confirm_delete_url`\nin the 200 response is `null`.\n\nAs an example of the deletion process,\nlet's imagine that you added a workflow that configured a particular code scanning tool\nto analyze the code in a repository. This tool has added 15 analyses:\n10 on the default branch, and another 5 on a topic branch.\nYou therefore have two separate sets of analyses for this tool.\nYou've now decided that you want to remove all of the analyses for the tool.\nTo do this you must make 15 separate deletion requests.\nTo start, you must find an analysis that's identified as deletable.\nEach set of analyses always has one that's identified as deletable.\nHaving found the deletable analysis for one of the two sets,\ndelete this analysis and then continue deleting the next analysis in the set until they're all deleted.\nThen repeat the process for the second set.\nThe procedure therefore consists of a nested loop:\n\n**Outer loop**:\n* List the analyses for the repository, filtered by tool.\n* Parse this list to find a deletable analysis. If found:\n **Inner loop**:\n * Delete the identified analysis.\n * Parse the response for the value of `confirm_delete_url` and, if found, use this in the next iteration.\nThe above process assumes that you want to remove all trace of the tool's analyses from the GitHub user interface, for the specified repository, and it therefore uses the `confirm_delete_url` value. Alternatively, you could use the `next_analysis_url` value, which would leave the last analysis in each set undeleted to avoid removing a tool's analysis entirely.",
|
||||
"operationId": "code-scanning/delete-analysis",
|
||||
"tags": [
|
||||
"code-scanning"
|
||||
@@ -41088,7 +41088,7 @@
|
||||
"categoryLabel": "Code scanning",
|
||||
"notes": [],
|
||||
"bodyParameters": [],
|
||||
"descriptionHTML": "<p>Deletes a specified code scanning analysis from a repository. For\nprivate repositories, you must use an access token with the <code>repo</code> scope. For public repositories,\nyou must use an access token with <code>public_repo</code> and <code>repo:security_events</code> scopes.\nGitHub Apps must have the <code>security_events</code> write permission to use this endpoint.</p>\n<p>You can delete one analysis at a time.\nTo delete a series of analyses, start with the most recent analysis and work backwards.\nConceptually, the process is similar to the undo function in a text editor.</p>\n<p>When you list the analyses for a repository,\none or more will be identified as deletable in the response:</p>\n<pre><code>\"deletable\": true\n</code></pre>\n<p>An analysis is deletable when it's the most recent in a set of analyses.\nTypically, a repository will have multiple sets of analyses\nfor each enabled code scanning tool,\nwhere a set is determined by a unique combination of analysis values:</p>\n<ul>\n<li><code>ref</code></li>\n<li><code>tool</code></li>\n<li><code>analysis_key</code></li>\n<li><code>environment</code></li>\n</ul>\n<p>If you attempt to delete an analysis that is not the most recent in a set,\nyou'll get a 400 response with the message:</p>\n<pre><code>Analysis specified is not deletable.\n</code></pre>\n<p>The response from a successful <code>DELETE</code> operation provides you with\ntwo alternative URLs for deleting the next analysis in the set:\n<code>next_analysis_url</code> and <code>confirm_delete_url</code>.\nUse the <code>next_analysis_url</code> URL if you want to avoid accidentally deleting the final analysis\nin a set. This is a useful option if you want to preserve at least one analysis\nfor the specified tool in your repository.\nUse the <code>confirm_delete_url</code> URL if you are content to remove all analyses for a tool.\nWhen you delete the last analysis in a set, the value of <code>next_analysis_url</code> and <code>confirm_delete_url</code>\nin the 200 response is <code>null</code>.</p>\n<p>As an example of the deletion process,\nlet's imagine that you added a workflow that configured a particular code scanning tool\nto analyze the code in a repository. This tool has added 15 analyses:\n10 on the default branch, and another 5 on a topic branch.\nYou therefore have two separate sets of analyses for this tool.\nYou've now decided that you want to remove all of the analyses for the tool.\nTo do this you must make 15 separate deletion requests.\nTo start, you must find an analysis that's identified as deletable.\nEach set of analyses always has one that's identified as deletable.\nHaving found the deletable analysis for one of the two sets,\ndelete this analysis and then continue deleting the next analysis in the set until they're all deleted.\nThen repeat the process for the second set.\nThe procedure therefore consists of a nested loop:</p>\n<p><strong>Outer loop</strong>:</p>\n<ul>\n<li>\n<p>List the analyses for the repository, filtered by tool.</p>\n</li>\n<li>\n<p>Parse this list to find a deletable analysis. If found:</p>\n<p><strong>Inner loop</strong>:</p>\n<ul>\n<li>Delete the identified analysis.</li>\n<li>Parse the response for the value of <code>confirm_delete_url</code> and, if found, use this in the next iteration.</li>\n</ul>\n</li>\n</ul>\n<p>The above process assumes that you want to remove all trace of the tool's analyses from the GitHub user interface, for the specified repository, and it therefore uses the <code>confirm_delete_url</code> value. Alternatively, you could use the <code>next_analysis_url</code> value, which would leave the last analysis in each set undeleted to avoid removing a tool's analysis entirely.</p>",
|
||||
"descriptionHTML": "<p>Deletes a specified code scanning analysis from a repository. For\nprivate repositories, you must use an access token with the <code>repo</code> scope. For public repositories,\nyou must use an access token with <code>public_repo</code> and <code>repo:security_events</code> scopes.\nGitHub Apps must have the <code>security_events</code> write permission to use this endpoint.</p>\n<p>You can delete one analysis at a time.\nTo delete a series of analyses, start with the most recent analysis and work backwards.\nConceptually, the process is similar to the undo function in a text editor.</p>\n<p>When you list the analyses for a repository,\none or more will be identified as deletable in the response:</p>\n<pre><code>\"deletable\": true\n</code></pre>\n<p>An analysis is deletable when it's the most recent in a set of analyses.\nTypically, a repository will have multiple sets of analyses\nfor each enabled code scanning tool,\nwhere a set is determined by a unique combination of analysis values:</p>\n<ul>\n<li><code>ref</code></li>\n<li><code>tool</code></li>\n<li><code>analysis_key</code></li>\n<li><code>environment</code></li>\n</ul>\n<p>If you attempt to delete an analysis that is not the most recent in a set,\nyou'll get a 400 response with the message:</p>\n<pre><code>Analysis specified is not deletable.\n</code></pre>\n<p>The response from a successful <code>DELETE</code> operation provides you with\ntwo alternative URLs for deleting the next analysis in the set:\n<code>next_analysis_url</code> and <code>confirm_delete_url</code>.\nUse the <code>next_analysis_url</code> URL if you want to avoid accidentally deleting the final analysis\nin a set. This is a useful option if you want to preserve at least one analysis\nfor the specified tool in your repository.\nUse the <code>confirm_delete_url</code> URL if you are content to remove all analyses for a tool.\nWhen you delete the last analysis in a set, the value of <code>next_analysis_url</code> and <code>confirm_delete_url</code>\nin the 200 response is <code>null</code>.</p>\n<p>As an example of the deletion process,\nlet's imagine that you added a workflow that configured a particular code scanning tool\nto analyze the code in a repository. This tool has added 15 analyses:\n10 on the default branch, and another 5 on a topic branch.\nYou therefore have two separate sets of analyses for this tool.\nYou've now decided that you want to remove all of the analyses for the tool.\nTo do this you must make 15 separate deletion requests.\nTo start, you must find an analysis that's identified as deletable.\nEach set of analyses always has one that's identified as deletable.\nHaving found the deletable analysis for one of the two sets,\ndelete this analysis and then continue deleting the next analysis in the set until they're all deleted.\nThen repeat the process for the second set.\nThe procedure therefore consists of a nested loop:</p>\n<p><strong>Outer loop</strong>:</p>\n<ul>\n<li>List the analyses for the repository, filtered by tool.</li>\n<li>Parse this list to find a deletable analysis. If found:\n<strong>Inner loop</strong>:\n<ul>\n<li>Delete the identified analysis.</li>\n<li>Parse the response for the value of <code>confirm_delete_url</code> and, if found, use this in the next iteration.\nThe above process assumes that you want to remove all trace of the tool's analyses from the GitHub user interface, for the specified repository, and it therefore uses the <code>confirm_delete_url</code> value. Alternatively, you could use the <code>next_analysis_url</code> value, which would leave the last analysis in each set undeleted to avoid removing a tool's analysis entirely.</li>\n</ul>\n</li>\n</ul>",
|
||||
"responses": [
|
||||
{
|
||||
"httpStatusCode": "200",
|
||||
@@ -41155,7 +41155,7 @@
|
||||
}
|
||||
],
|
||||
"summary": "Upload an analysis as SARIF data",
|
||||
"description": "Uploads SARIF data containing the results of a code scanning analysis to make the results available in a repository. You must use an access token with the `security_events` scope to use this endpoint. GitHub Apps must have the `security_events` write permission to use this endpoint.\n\nThere are two places where you can upload code scanning results.\n - If you upload to a pull request, for example `--ref refs/pull/42/merge` or `--ref refs/pull/42/head`, then the results appear as alerts in a pull request check. For more information, see \"[Triaging code scanning alerts in pull requests](/code-security/secure-coding/triaging-code-scanning-alerts-in-pull-requests).\"\n - If you upload to a branch, for example `--ref refs/heads/my-branch`, then the results appear in the **Security** tab for your repository. For more information, see \"[Managing code scanning alerts for your repository](/code-security/secure-coding/managing-code-scanning-alerts-for-your-repository#viewing-the-alerts-for-a-repository).\"\n\nYou must compress the SARIF-formatted analysis data that you want to upload, using `gzip`, and then encode it as a Base64 format string. For example:\n\n```\ngzip -c analysis-data.sarif | base64 -w0\n```\n\nSARIF upload supports a maximum of 5000 results per analysis run. Any results over this limit are ignored and any SARIF uploads with more than 25,000 results are rejected. Typically, but not necessarily, a SARIF file contains a single run of a single tool. If a code scanning tool generates too many results, you should update the analysis configuration to run only the most important rules or queries.\n\nThe `202 Accepted`, response includes an `id` value.\nYou can use this ID to check the status of the upload by using this for the `/sarifs/{sarif_id}` endpoint.\nFor more information, see \"[Get information about a SARIF upload](/rest/reference/code-scanning#get-information-about-a-sarif-upload).\"",
|
||||
"description": "Uploads SARIF data containing the results of a code scanning analysis to make the results available in a repository. You must use an access token with the `security_events` scope to use this endpoint. GitHub Apps must have the `security_events` write permission to use this endpoint.\n\nThere are two places where you can upload code scanning results.\n - If you upload to a pull request, for example `--ref refs/pull/42/merge` or `--ref refs/pull/42/head`, then the results appear as alerts in a pull request check. For more information, see \"[Triaging code scanning alerts in pull requests](/code-security/secure-coding/triaging-code-scanning-alerts-in-pull-requests).\"\n - If you upload to a branch, for example `--ref refs/heads/my-branch`, then the results appear in the **Security** tab for your repository. For more information, see \"[Managing code scanning alerts for your repository](/code-security/secure-coding/managing-code-scanning-alerts-for-your-repository#viewing-the-alerts-for-a-repository).\"\n\nYou must compress the SARIF-formatted analysis data that you want to upload, using `gzip`, and then encode it as a Base64 format string. For example:\n\n```\ngzip -c analysis-data.sarif | base64 -w0\n```\n\nSARIF upload supports a maximum of 5000 results per analysis run. Any results over this limit are ignored. Typically, but not necessarily, a SARIF file contains a single run of a single tool. If a code scanning tool generates too many results, you should update the analysis configuration to run only the most important rules or queries.\n\nThe `202 Accepted`, response includes an `id` value.\nYou can use this ID to check the status of the upload by using this for the `/sarifs/{sarif_id}` endpoint.\nFor more information, see \"[Get information about a SARIF upload](/rest/reference/code-scanning#get-information-about-a-sarif-upload).\"",
|
||||
"operationId": "code-scanning/upload-sarif",
|
||||
"tags": [
|
||||
"code-scanning"
|
||||
@@ -41251,7 +41251,7 @@
|
||||
"categoryLabel": "Code scanning",
|
||||
"contentType": "application/json",
|
||||
"notes": [],
|
||||
"descriptionHTML": "<p>Uploads SARIF data containing the results of a code scanning analysis to make the results available in a repository. You must use an access token with the <code>security_events</code> scope to use this endpoint. GitHub Apps must have the <code>security_events</code> write permission to use this endpoint.</p>\n<p>There are two places where you can upload code scanning results.</p>\n<ul>\n<li>If you upload to a pull request, for example <code>--ref refs/pull/42/merge</code> or <code>--ref refs/pull/42/head</code>, then the results appear as alerts in a pull request check. For more information, see \"<a href=\"/code-security/secure-coding/triaging-code-scanning-alerts-in-pull-requests\">Triaging code scanning alerts in pull requests</a>.\"</li>\n<li>If you upload to a branch, for example <code>--ref refs/heads/my-branch</code>, then the results appear in the <strong>Security</strong> tab for your repository. For more information, see \"<a href=\"/code-security/secure-coding/managing-code-scanning-alerts-for-your-repository#viewing-the-alerts-for-a-repository\">Managing code scanning alerts for your repository</a>.\"</li>\n</ul>\n<p>You must compress the SARIF-formatted analysis data that you want to upload, using <code>gzip</code>, and then encode it as a Base64 format string. For example:</p>\n<pre><code>gzip -c analysis-data.sarif | base64 -w0\n</code></pre>\n<p>SARIF upload supports a maximum of 5000 results per analysis run. Any results over this limit are ignored and any SARIF uploads with more than 25,000 results are rejected. Typically, but not necessarily, a SARIF file contains a single run of a single tool. If a code scanning tool generates too many results, you should update the analysis configuration to run only the most important rules or queries.</p>\n<p>The <code>202 Accepted</code>, response includes an <code>id</code> value.\nYou can use this ID to check the status of the upload by using this for the <code>/sarifs/{sarif_id}</code> endpoint.\nFor more information, see \"<a href=\"/rest/reference/code-scanning#get-information-about-a-sarif-upload\">Get information about a SARIF upload</a>.\"</p>",
|
||||
"descriptionHTML": "<p>Uploads SARIF data containing the results of a code scanning analysis to make the results available in a repository. You must use an access token with the <code>security_events</code> scope to use this endpoint. GitHub Apps must have the <code>security_events</code> write permission to use this endpoint.</p>\n<p>There are two places where you can upload code scanning results.</p>\n<ul>\n<li>If you upload to a pull request, for example <code>--ref refs/pull/42/merge</code> or <code>--ref refs/pull/42/head</code>, then the results appear as alerts in a pull request check. For more information, see \"<a href=\"/code-security/secure-coding/triaging-code-scanning-alerts-in-pull-requests\">Triaging code scanning alerts in pull requests</a>.\"</li>\n<li>If you upload to a branch, for example <code>--ref refs/heads/my-branch</code>, then the results appear in the <strong>Security</strong> tab for your repository. For more information, see \"<a href=\"/code-security/secure-coding/managing-code-scanning-alerts-for-your-repository#viewing-the-alerts-for-a-repository\">Managing code scanning alerts for your repository</a>.\"</li>\n</ul>\n<p>You must compress the SARIF-formatted analysis data that you want to upload, using <code>gzip</code>, and then encode it as a Base64 format string. For example:</p>\n<pre><code>gzip -c analysis-data.sarif | base64 -w0\n</code></pre>\n<p>SARIF upload supports a maximum of 5000 results per analysis run. Any results over this limit are ignored. Typically, but not necessarily, a SARIF file contains a single run of a single tool. If a code scanning tool generates too many results, you should update the analysis configuration to run only the most important rules or queries.</p>\n<p>The <code>202 Accepted</code>, response includes an <code>id</code> value.\nYou can use this ID to check the status of the upload by using this for the <code>/sarifs/{sarif_id}</code> endpoint.\nFor more information, see \"<a href=\"/rest/reference/code-scanning#get-information-about-a-sarif-upload\">Get information about a SARIF upload</a>.\"</p>",
|
||||
"bodyParameters": [
|
||||
{
|
||||
"description": "<p><strong>Required</strong>. The SHA of the commit to which the analysis you are uploading relates.</p>",
|
||||
@@ -56253,7 +56253,7 @@
|
||||
}
|
||||
],
|
||||
"summary": "Enable Git LFS for a repository",
|
||||
"description": "**Note:** The Git LFS API endpoints are currently in beta and are subject to change.",
|
||||
"description": "",
|
||||
"operationId": "repos/enable-lfs-for-repo",
|
||||
"tags": [
|
||||
"repos"
|
||||
@@ -56274,6 +56274,7 @@
|
||||
"subcategory": "lfs",
|
||||
"subcategoryLabel": "Lfs",
|
||||
"notes": [],
|
||||
"descriptionHTML": "",
|
||||
"responses": [
|
||||
{
|
||||
"httpStatusCode": "202",
|
||||
@@ -56286,8 +56287,7 @@
|
||||
"description": "We will return a 403 with one of the following messages:\n\n- Git LFS support not enabled because Git LFS is globally disabled.\n- Git LFS support not enabled because Git LFS is disabled for the root repository in the network.\n- Git LFS support not enabled because Git LFS is disabled for <owner>."
|
||||
}
|
||||
],
|
||||
"bodyParameters": [],
|
||||
"descriptionHTML": "<p><strong>Note:</strong> The Git LFS API endpoints are currently in beta and are subject to change.</p>"
|
||||
"bodyParameters": []
|
||||
},
|
||||
{
|
||||
"verb": "delete",
|
||||
@@ -56326,7 +56326,7 @@
|
||||
}
|
||||
],
|
||||
"summary": "Disable Git LFS for a repository",
|
||||
"description": "**Note:** The Git LFS API endpoints are currently in beta and are subject to change.",
|
||||
"description": "",
|
||||
"operationId": "repos/disable-lfs-for-repo",
|
||||
"tags": [
|
||||
"repos"
|
||||
@@ -56347,6 +56347,7 @@
|
||||
"subcategory": "lfs",
|
||||
"subcategoryLabel": "Lfs",
|
||||
"notes": [],
|
||||
"descriptionHTML": "",
|
||||
"responses": [
|
||||
{
|
||||
"httpStatusCode": "204",
|
||||
@@ -56354,8 +56355,7 @@
|
||||
"description": "Response"
|
||||
}
|
||||
],
|
||||
"bodyParameters": [],
|
||||
"descriptionHTML": "<p><strong>Note:</strong> The Git LFS API endpoints are currently in beta and are subject to change.</p>"
|
||||
"bodyParameters": []
|
||||
},
|
||||
{
|
||||
"verb": "get",
|
||||
@@ -56461,7 +56461,7 @@
|
||||
}
|
||||
],
|
||||
"summary": "Sync a fork branch with the upstream repository",
|
||||
"description": "**Note:** This endpoint is currently in beta and subject to change.\n\nSync a branch of a forked repository to keep it up-to-date with the upstream repository.",
|
||||
"description": "Sync a branch of a forked repository to keep it up-to-date with the upstream repository.",
|
||||
"tags": [
|
||||
"repos"
|
||||
],
|
||||
@@ -56510,7 +56510,7 @@
|
||||
"subcategoryLabel": "Branches",
|
||||
"contentType": "application/json",
|
||||
"notes": [],
|
||||
"descriptionHTML": "<p><strong>Note:</strong> This endpoint is currently in beta and subject to change.</p>\n<p>Sync a branch of a forked repository to keep it up-to-date with the upstream repository.</p>",
|
||||
"descriptionHTML": "<p>Sync a branch of a forked repository to keep it up-to-date with the upstream repository.</p>",
|
||||
"bodyParameters": [
|
||||
{
|
||||
"type": "string",
|
||||
|
||||
@@ -23143,7 +23143,7 @@
|
||||
},
|
||||
"x-github": {
|
||||
"githubCloudOnly": false,
|
||||
"enabledForGitHubApps": true,
|
||||
"enabledForGitHubApps": false,
|
||||
"previews": [
|
||||
|
||||
],
|
||||
@@ -182340,7 +182340,7 @@
|
||||
},
|
||||
"patch": {
|
||||
"summary": "Update a code scanning alert",
|
||||
"description": "Updates the status of a single code scanning alert. You must use an access token with the `security_events` scope to use this endpoint. GitHub Apps must have the `security_events` write permission to use this endpoint.",
|
||||
"description": "Updates the status of a single code scanning alert. You must use an access token with the `security_events` scope to use this endpoint with private repositories. You can also use tokens with the `public_repo` scope for public repositories only. GitHub Apps must have the `security_events` write permission to use this endpoint.",
|
||||
"operationId": "code-scanning/update-alert",
|
||||
"tags": [
|
||||
"code-scanning"
|
||||
@@ -183834,7 +183834,7 @@
|
||||
},
|
||||
"delete": {
|
||||
"summary": "Delete a code scanning analysis from a repository",
|
||||
"description": "Deletes a specified code scanning analysis from a repository. For\nprivate repositories, you must use an access token with the `repo` scope. For public repositories,\nyou must use an access token with `public_repo` and `repo:security_events` scopes.\nGitHub Apps must have the `security_events` write permission to use this endpoint.\n\nYou can delete one analysis at a time.\nTo delete a series of analyses, start with the most recent analysis and work backwards.\nConceptually, the process is similar to the undo function in a text editor.\n\nWhen you list the analyses for a repository,\none or more will be identified as deletable in the response:\n\n```\n\"deletable\": true\n```\n\nAn analysis is deletable when it's the most recent in a set of analyses.\nTypically, a repository will have multiple sets of analyses\nfor each enabled code scanning tool,\nwhere a set is determined by a unique combination of analysis values:\n\n* `ref`\n* `tool`\n* `analysis_key`\n* `environment`\n\nIf you attempt to delete an analysis that is not the most recent in a set,\nyou'll get a 400 response with the message:\n\n```\nAnalysis specified is not deletable.\n```\n\nThe response from a successful `DELETE` operation provides you with\ntwo alternative URLs for deleting the next analysis in the set:\n`next_analysis_url` and `confirm_delete_url`.\nUse the `next_analysis_url` URL if you want to avoid accidentally deleting the final analysis\nin a set. This is a useful option if you want to preserve at least one analysis\nfor the specified tool in your repository.\nUse the `confirm_delete_url` URL if you are content to remove all analyses for a tool.\nWhen you delete the last analysis in a set, the value of `next_analysis_url` and `confirm_delete_url`\nin the 200 response is `null`.\n\nAs an example of the deletion process,\nlet's imagine that you added a workflow that configured a particular code scanning tool\nto analyze the code in a repository. This tool has added 15 analyses:\n10 on the default branch, and another 5 on a topic branch.\nYou therefore have two separate sets of analyses for this tool.\nYou've now decided that you want to remove all of the analyses for the tool.\nTo do this you must make 15 separate deletion requests.\nTo start, you must find an analysis that's identified as deletable.\nEach set of analyses always has one that's identified as deletable.\nHaving found the deletable analysis for one of the two sets,\ndelete this analysis and then continue deleting the next analysis in the set until they're all deleted.\nThen repeat the process for the second set.\nThe procedure therefore consists of a nested loop:\n\n**Outer loop**:\n* List the analyses for the repository, filtered by tool.\n* Parse this list to find a deletable analysis. If found:\n\n **Inner loop**:\n * Delete the identified analysis.\n * Parse the response for the value of `confirm_delete_url` and, if found, use this in the next iteration.\n\nThe above process assumes that you want to remove all trace of the tool's analyses from the GitHub user interface, for the specified repository, and it therefore uses the `confirm_delete_url` value. Alternatively, you could use the `next_analysis_url` value, which would leave the last analysis in each set undeleted to avoid removing a tool's analysis entirely.",
|
||||
"description": "Deletes a specified code scanning analysis from a repository. For\nprivate repositories, you must use an access token with the `repo` scope. For public repositories,\nyou must use an access token with `public_repo` scope.\nGitHub Apps must have the `security_events` write permission to use this endpoint.\n\nYou can delete one analysis at a time.\nTo delete a series of analyses, start with the most recent analysis and work backwards.\nConceptually, the process is similar to the undo function in a text editor.\n\nWhen you list the analyses for a repository,\none or more will be identified as deletable in the response:\n\n```\n\"deletable\": true\n```\n\nAn analysis is deletable when it's the most recent in a set of analyses.\nTypically, a repository will have multiple sets of analyses\nfor each enabled code scanning tool,\nwhere a set is determined by a unique combination of analysis values:\n\n* `ref`\n* `tool`\n* `analysis_key`\n* `environment`\n\nIf you attempt to delete an analysis that is not the most recent in a set,\nyou'll get a 400 response with the message:\n\n```\nAnalysis specified is not deletable.\n```\n\nThe response from a successful `DELETE` operation provides you with\ntwo alternative URLs for deleting the next analysis in the set:\n`next_analysis_url` and `confirm_delete_url`.\nUse the `next_analysis_url` URL if you want to avoid accidentally deleting the final analysis\nin a set. This is a useful option if you want to preserve at least one analysis\nfor the specified tool in your repository.\nUse the `confirm_delete_url` URL if you are content to remove all analyses for a tool.\nWhen you delete the last analysis in a set, the value of `next_analysis_url` and `confirm_delete_url`\nin the 200 response is `null`.\n\nAs an example of the deletion process,\nlet's imagine that you added a workflow that configured a particular code scanning tool\nto analyze the code in a repository. This tool has added 15 analyses:\n10 on the default branch, and another 5 on a topic branch.\nYou therefore have two separate sets of analyses for this tool.\nYou've now decided that you want to remove all of the analyses for the tool.\nTo do this you must make 15 separate deletion requests.\nTo start, you must find an analysis that's identified as deletable.\nEach set of analyses always has one that's identified as deletable.\nHaving found the deletable analysis for one of the two sets,\ndelete this analysis and then continue deleting the next analysis in the set until they're all deleted.\nThen repeat the process for the second set.\nThe procedure therefore consists of a nested loop:\n\n**Outer loop**:\n* List the analyses for the repository, filtered by tool.\n* Parse this list to find a deletable analysis. If found:\n\n **Inner loop**:\n * Delete the identified analysis.\n * Parse the response for the value of `confirm_delete_url` and, if found, use this in the next iteration.\n\nThe above process assumes that you want to remove all trace of the tool's analyses from the GitHub user interface, for the specified repository, and it therefore uses the `confirm_delete_url` value. Alternatively, you could use the `next_analysis_url` value, which would leave the last analysis in each set undeleted to avoid removing a tool's analysis entirely.",
|
||||
"operationId": "code-scanning/delete-analysis",
|
||||
"tags": [
|
||||
"code-scanning"
|
||||
@@ -184066,7 +184066,7 @@
|
||||
"/repos/{owner}/{repo}/code-scanning/sarifs": {
|
||||
"post": {
|
||||
"summary": "Upload an analysis as SARIF data",
|
||||
"description": "Uploads SARIF data containing the results of a code scanning analysis to make the results available in a repository. You must use an access token with the `security_events` scope to use this endpoint. GitHub Apps must have the `security_events` write permission to use this endpoint.\n\nThere are two places where you can upload code scanning results.\n - If you upload to a pull request, for example `--ref refs/pull/42/merge` or `--ref refs/pull/42/head`, then the results appear as alerts in a pull request check. For more information, see \"[Triaging code scanning alerts in pull requests](/code-security/secure-coding/triaging-code-scanning-alerts-in-pull-requests).\"\n - If you upload to a branch, for example `--ref refs/heads/my-branch`, then the results appear in the **Security** tab for your repository. For more information, see \"[Managing code scanning alerts for your repository](/code-security/secure-coding/managing-code-scanning-alerts-for-your-repository#viewing-the-alerts-for-a-repository).\"\n\nYou must compress the SARIF-formatted analysis data that you want to upload, using `gzip`, and then encode it as a Base64 format string. For example:\n\n```\ngzip -c analysis-data.sarif | base64 -w0\n```\n\nSARIF upload supports a maximum of 5000 results per analysis run. Any results over this limit are ignored and any SARIF uploads with more than 25,000 results are rejected. Typically, but not necessarily, a SARIF file contains a single run of a single tool. If a code scanning tool generates too many results, you should update the analysis configuration to run only the most important rules or queries.\n\nThe `202 Accepted`, response includes an `id` value.\nYou can use this ID to check the status of the upload by using this for the `/sarifs/{sarif_id}` endpoint.\nFor more information, see \"[Get information about a SARIF upload](/rest/reference/code-scanning#get-information-about-a-sarif-upload).\"",
|
||||
"description": "Uploads SARIF data containing the results of a code scanning analysis to make the results available in a repository. You must use an access token with the `security_events` scope to use this endpoint for private repositories. You can also use tokens with the `public_repo` scope for public repositories only. GitHub Apps must have the `security_events` write permission to use this endpoint.\n\nThere are two places where you can upload code scanning results.\n - If you upload to a pull request, for example `--ref refs/pull/42/merge` or `--ref refs/pull/42/head`, then the results appear as alerts in a pull request check. For more information, see \"[Triaging code scanning alerts in pull requests](/code-security/secure-coding/triaging-code-scanning-alerts-in-pull-requests).\"\n - If you upload to a branch, for example `--ref refs/heads/my-branch`, then the results appear in the **Security** tab for your repository. For more information, see \"[Managing code scanning alerts for your repository](/code-security/secure-coding/managing-code-scanning-alerts-for-your-repository#viewing-the-alerts-for-a-repository).\"\n\nYou must compress the SARIF-formatted analysis data that you want to upload, using `gzip`, and then encode it as a Base64 format string. For example:\n\n```\ngzip -c analysis-data.sarif | base64 -w0\n```\n\nSARIF upload supports a maximum of 5000 results per analysis run. Any results over this limit are ignored and any SARIF uploads with more than 25,000 results are rejected. Typically, but not necessarily, a SARIF file contains a single run of a single tool. If a code scanning tool generates too many results, you should update the analysis configuration to run only the most important rules or queries.\n\nThe `202 Accepted`, response includes an `id` value.\nYou can use this ID to check the status of the upload by using this for the `/sarifs/{sarif_id}` endpoint.\nFor more information, see \"[Get information about a SARIF upload](/rest/reference/code-scanning#get-information-about-a-sarif-upload).\"",
|
||||
"operationId": "code-scanning/upload-sarif",
|
||||
"tags": [
|
||||
"code-scanning"
|
||||
@@ -295058,7 +295058,7 @@
|
||||
"/repos/{owner}/{repo}/lfs": {
|
||||
"put": {
|
||||
"summary": "Enable Git LFS for a repository",
|
||||
"description": "**Note:** The Git LFS API endpoints are currently in beta and are subject to change.",
|
||||
"description": "",
|
||||
"operationId": "repos/enable-lfs-for-repo",
|
||||
"tags": [
|
||||
"repos"
|
||||
@@ -295109,7 +295109,7 @@
|
||||
},
|
||||
"delete": {
|
||||
"summary": "Disable Git LFS for a repository",
|
||||
"description": "**Note:** The Git LFS API endpoints are currently in beta and are subject to change.",
|
||||
"description": "",
|
||||
"operationId": "repos/disable-lfs-for-repo",
|
||||
"tags": [
|
||||
"repos"
|
||||
@@ -295356,7 +295356,7 @@
|
||||
"/repos/{owner}/{repo}/merge-upstream": {
|
||||
"post": {
|
||||
"summary": "Sync a fork branch with the upstream repository",
|
||||
"description": "**Note:** This endpoint is currently in beta and subject to change.\n\nSync a branch of a forked repository to keep it up-to-date with the upstream repository.",
|
||||
"description": "Sync a branch of a forked repository to keep it up-to-date with the upstream repository.",
|
||||
"tags": [
|
||||
"repos"
|
||||
],
|
||||
|
||||
@@ -271583,7 +271583,7 @@
|
||||
"/repos/{owner}/{repo}/lfs": {
|
||||
"put": {
|
||||
"summary": "Enable Git LFS for a repository",
|
||||
"description": "**Note:** The Git LFS API endpoints are currently in beta and are subject to change.",
|
||||
"description": "",
|
||||
"operationId": "repos/enable-lfs-for-repo",
|
||||
"tags": [
|
||||
"repos"
|
||||
@@ -271634,7 +271634,7 @@
|
||||
},
|
||||
"delete": {
|
||||
"summary": "Disable Git LFS for a repository",
|
||||
"description": "**Note:** The Git LFS API endpoints are currently in beta and are subject to change.",
|
||||
"description": "",
|
||||
"operationId": "repos/disable-lfs-for-repo",
|
||||
"tags": [
|
||||
"repos"
|
||||
@@ -271881,7 +271881,7 @@
|
||||
"/repos/{owner}/{repo}/merge-upstream": {
|
||||
"post": {
|
||||
"summary": "Sync a fork branch with the upstream repository",
|
||||
"description": "**Note:** This endpoint is currently in beta and subject to change.\n\nSync a branch of a forked repository to keep it up-to-date with the upstream repository.",
|
||||
"description": "Sync a branch of a forked repository to keep it up-to-date with the upstream repository.",
|
||||
"tags": [
|
||||
"repos"
|
||||
],
|
||||
|
||||
@@ -133209,7 +133209,7 @@
|
||||
},
|
||||
"delete": {
|
||||
"summary": "Delete a code scanning analysis from a repository",
|
||||
"description": "Deletes a specified code scanning analysis from a repository. For\nprivate repositories, you must use an access token with the `repo` scope. For public repositories,\nyou must use an access token with `public_repo` and `repo:security_events` scopes.\nGitHub Apps must have the `security_events` write permission to use this endpoint.\n\nYou can delete one analysis at a time.\nTo delete a series of analyses, start with the most recent analysis and work backwards.\nConceptually, the process is similar to the undo function in a text editor.\n\nWhen you list the analyses for a repository,\none or more will be identified as deletable in the response:\n\n```\n\"deletable\": true\n```\n\nAn analysis is deletable when it's the most recent in a set of analyses.\nTypically, a repository will have multiple sets of analyses\nfor each enabled code scanning tool,\nwhere a set is determined by a unique combination of analysis values:\n\n* `ref`\n* `tool`\n* `analysis_key`\n* `environment`\n\nIf you attempt to delete an analysis that is not the most recent in a set,\nyou'll get a 400 response with the message:\n\n```\nAnalysis specified is not deletable.\n```\n\nThe response from a successful `DELETE` operation provides you with\ntwo alternative URLs for deleting the next analysis in the set:\n`next_analysis_url` and `confirm_delete_url`.\nUse the `next_analysis_url` URL if you want to avoid accidentally deleting the final analysis\nin a set. This is a useful option if you want to preserve at least one analysis\nfor the specified tool in your repository.\nUse the `confirm_delete_url` URL if you are content to remove all analyses for a tool.\nWhen you delete the last analysis in a set, the value of `next_analysis_url` and `confirm_delete_url`\nin the 200 response is `null`.\n\nAs an example of the deletion process,\nlet's imagine that you added a workflow that configured a particular code scanning tool\nto analyze the code in a repository. This tool has added 15 analyses:\n10 on the default branch, and another 5 on a topic branch.\nYou therefore have two separate sets of analyses for this tool.\nYou've now decided that you want to remove all of the analyses for the tool.\nTo do this you must make 15 separate deletion requests.\nTo start, you must find an analysis that's identified as deletable.\nEach set of analyses always has one that's identified as deletable.\nHaving found the deletable analysis for one of the two sets,\ndelete this analysis and then continue deleting the next analysis in the set until they're all deleted.\nThen repeat the process for the second set.\nThe procedure therefore consists of a nested loop:\n\n**Outer loop**:\n* List the analyses for the repository, filtered by tool.\n* Parse this list to find a deletable analysis. If found:\n\n **Inner loop**:\n * Delete the identified analysis.\n * Parse the response for the value of `confirm_delete_url` and, if found, use this in the next iteration.\n\nThe above process assumes that you want to remove all trace of the tool's analyses from the GitHub user interface, for the specified repository, and it therefore uses the `confirm_delete_url` value. Alternatively, you could use the `next_analysis_url` value, which would leave the last analysis in each set undeleted to avoid removing a tool's analysis entirely.",
|
||||
"description": "Deletes a specified code scanning analysis from a repository. For\nprivate repositories, you must use an access token with the `repo` scope. For public repositories,\nyou must use an access token with `public_repo` and `repo:security_events` scopes.\nGitHub Apps must have the `security_events` write permission to use this endpoint.\n\nYou can delete one analysis at a time.\nTo delete a series of analyses, start with the most recent analysis and work backwards.\nConceptually, the process is similar to the undo function in a text editor.\n\nWhen you list the analyses for a repository,\none or more will be identified as deletable in the response:\n\n```\n\"deletable\": true\n```\n\nAn analysis is deletable when it's the most recent in a set of analyses.\nTypically, a repository will have multiple sets of analyses\nfor each enabled code scanning tool,\nwhere a set is determined by a unique combination of analysis values:\n\n* `ref`\n* `tool`\n* `analysis_key`\n* `environment`\n\nIf you attempt to delete an analysis that is not the most recent in a set,\nyou'll get a 400 response with the message:\n\n```\nAnalysis specified is not deletable.\n```\n\nThe response from a successful `DELETE` operation provides you with\ntwo alternative URLs for deleting the next analysis in the set:\n`next_analysis_url` and `confirm_delete_url`.\nUse the `next_analysis_url` URL if you want to avoid accidentally deleting the final analysis\nin a set. This is a useful option if you want to preserve at least one analysis\nfor the specified tool in your repository.\nUse the `confirm_delete_url` URL if you are content to remove all analyses for a tool.\nWhen you delete the last analysis in a set, the value of `next_analysis_url` and `confirm_delete_url`\nin the 200 response is `null`.\n\nAs an example of the deletion process,\nlet's imagine that you added a workflow that configured a particular code scanning tool\nto analyze the code in a repository. This tool has added 15 analyses:\n10 on the default branch, and another 5 on a topic branch.\nYou therefore have two separate sets of analyses for this tool.\nYou've now decided that you want to remove all of the analyses for the tool.\nTo do this you must make 15 separate deletion requests.\nTo start, you must find an analysis that's identified as deletable.\nEach set of analyses always has one that's identified as deletable.\nHaving found the deletable analysis for one of the two sets,\ndelete this analysis and then continue deleting the next analysis in the set until they're all deleted.\nThen repeat the process for the second set.\nThe procedure therefore consists of a nested loop:\n\n**Outer loop**:\n* List the analyses for the repository, filtered by tool.\n* Parse this list to find a deletable analysis. If found:\n **Inner loop**:\n * Delete the identified analysis.\n * Parse the response for the value of `confirm_delete_url` and, if found, use this in the next iteration.\nThe above process assumes that you want to remove all trace of the tool's analyses from the GitHub user interface, for the specified repository, and it therefore uses the `confirm_delete_url` value. Alternatively, you could use the `next_analysis_url` value, which would leave the last analysis in each set undeleted to avoid removing a tool's analysis entirely.",
|
||||
"operationId": "code-scanning/delete-analysis",
|
||||
"tags": [
|
||||
"code-scanning"
|
||||
@@ -133441,7 +133441,7 @@
|
||||
"/repos/{owner}/{repo}/code-scanning/sarifs": {
|
||||
"post": {
|
||||
"summary": "Upload an analysis as SARIF data",
|
||||
"description": "Uploads SARIF data containing the results of a code scanning analysis to make the results available in a repository. You must use an access token with the `security_events` scope to use this endpoint. GitHub Apps must have the `security_events` write permission to use this endpoint.\n\nThere are two places where you can upload code scanning results.\n - If you upload to a pull request, for example `--ref refs/pull/42/merge` or `--ref refs/pull/42/head`, then the results appear as alerts in a pull request check. For more information, see \"[Triaging code scanning alerts in pull requests](/code-security/secure-coding/triaging-code-scanning-alerts-in-pull-requests).\"\n - If you upload to a branch, for example `--ref refs/heads/my-branch`, then the results appear in the **Security** tab for your repository. For more information, see \"[Managing code scanning alerts for your repository](/code-security/secure-coding/managing-code-scanning-alerts-for-your-repository#viewing-the-alerts-for-a-repository).\"\n\nYou must compress the SARIF-formatted analysis data that you want to upload, using `gzip`, and then encode it as a Base64 format string. For example:\n\n```\ngzip -c analysis-data.sarif | base64 -w0\n```\n\nSARIF upload supports a maximum of 5000 results per analysis run. Any results over this limit are ignored and any SARIF uploads with more than 25,000 results are rejected. Typically, but not necessarily, a SARIF file contains a single run of a single tool. If a code scanning tool generates too many results, you should update the analysis configuration to run only the most important rules or queries.\n\nThe `202 Accepted`, response includes an `id` value.\nYou can use this ID to check the status of the upload by using this for the `/sarifs/{sarif_id}` endpoint.\nFor more information, see \"[Get information about a SARIF upload](/rest/reference/code-scanning#get-information-about-a-sarif-upload).\"",
|
||||
"description": "Uploads SARIF data containing the results of a code scanning analysis to make the results available in a repository. You must use an access token with the `security_events` scope to use this endpoint. GitHub Apps must have the `security_events` write permission to use this endpoint.\n\nThere are two places where you can upload code scanning results.\n - If you upload to a pull request, for example `--ref refs/pull/42/merge` or `--ref refs/pull/42/head`, then the results appear as alerts in a pull request check. For more information, see \"[Triaging code scanning alerts in pull requests](/code-security/secure-coding/triaging-code-scanning-alerts-in-pull-requests).\"\n - If you upload to a branch, for example `--ref refs/heads/my-branch`, then the results appear in the **Security** tab for your repository. For more information, see \"[Managing code scanning alerts for your repository](/code-security/secure-coding/managing-code-scanning-alerts-for-your-repository#viewing-the-alerts-for-a-repository).\"\n\nYou must compress the SARIF-formatted analysis data that you want to upload, using `gzip`, and then encode it as a Base64 format string. For example:\n\n```\ngzip -c analysis-data.sarif | base64 -w0\n```\n\nSARIF upload supports a maximum of 5000 results per analysis run. Any results over this limit are ignored. Typically, but not necessarily, a SARIF file contains a single run of a single tool. If a code scanning tool generates too many results, you should update the analysis configuration to run only the most important rules or queries.\n\nThe `202 Accepted`, response includes an `id` value.\nYou can use this ID to check the status of the upload by using this for the `/sarifs/{sarif_id}` endpoint.\nFor more information, see \"[Get information about a SARIF upload](/rest/reference/code-scanning#get-information-about-a-sarif-upload).\"",
|
||||
"operationId": "code-scanning/upload-sarif",
|
||||
"tags": [
|
||||
"code-scanning"
|
||||
@@ -232475,7 +232475,7 @@
|
||||
"/repos/{owner}/{repo}/lfs": {
|
||||
"put": {
|
||||
"summary": "Enable Git LFS for a repository",
|
||||
"description": "**Note:** The Git LFS API endpoints are currently in beta and are subject to change.",
|
||||
"description": "",
|
||||
"operationId": "repos/enable-lfs-for-repo",
|
||||
"tags": [
|
||||
"repos"
|
||||
@@ -232526,7 +232526,7 @@
|
||||
},
|
||||
"delete": {
|
||||
"summary": "Disable Git LFS for a repository",
|
||||
"description": "**Note:** The Git LFS API endpoints are currently in beta and are subject to change.",
|
||||
"description": "",
|
||||
"operationId": "repos/disable-lfs-for-repo",
|
||||
"tags": [
|
||||
"repos"
|
||||
@@ -232773,7 +232773,7 @@
|
||||
"/repos/{owner}/{repo}/merge-upstream": {
|
||||
"post": {
|
||||
"summary": "Sync a fork branch with the upstream repository",
|
||||
"description": "**Note:** This endpoint is currently in beta and subject to change.\n\nSync a branch of a forked repository to keep it up-to-date with the upstream repository.",
|
||||
"description": "Sync a branch of a forked repository to keep it up-to-date with the upstream repository.",
|
||||
"tags": [
|
||||
"repos"
|
||||
],
|
||||
|
||||
Reference in New Issue
Block a user