The status contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.
", + "description": "The status contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.
", "items": { "type": "string" }, "name": "required_contexts", "in": "body", "rawType": "array", - "rawDescription": "The [status](https://docs.github.com/rest/reference/repos#statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", + "rawDescription": "The [status](https://docs.github.com/rest/reference/commits#commit-statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", "childParamsGroups": [] }, "payload": { @@ -57685,7 +57685,7 @@ "categoryLabel": "Deployments", "contentType": "application/json", "notes": [], - "descriptionHTML": "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.
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.
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.
The status contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.
", + "description": "The status contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.
", "items": { "type": "string" }, "name": "required_contexts", "in": "body", "rawType": "array", - "rawDescription": "The [status](https://docs.github.com/rest/reference/repos#statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", + "rawDescription": "The [status](https://docs.github.com/rest/reference/commits#commit-statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", "childParamsGroups": [] }, { @@ -57941,7 +57941,7 @@ } ], "summary": "Delete a deployment", - "description": "To ensure there can always be an active deployment, you can only delete an _inactive_ deployment. Anyone with `repo` or `repo_deployment` scopes can delete an inactive deployment.\n\nTo set a deployment as inactive, you must:\n\n* Create a new deployment that is active so that the system has a record of the current state, then delete the previously active deployment.\n* Mark the active deployment as inactive by adding any non-successful deployment status.\n\nFor more information, see \"[Create a deployment](https://docs.github.com/rest/reference/repos/#create-a-deployment)\" and \"[Create a deployment status](https://docs.github.com/rest/reference/repos#create-a-deployment-status).\"", + "description": "If the repository only has one deployment, you can delete the deployment regardless of its status. If the repository has more than one deployment, you can only delete inactive deployments. This ensures that repositories with multiple deployments will always have an active deployment. Anyone with `repo` or `repo_deployment` scopes can delete a deployment.\n\nTo set a deployment as inactive, you must:\n\n* Create a new deployment that is active so that the system has a record of the current state, then delete the previously active deployment.\n* Mark the active deployment as inactive by adding any non-successful deployment status.\n\nFor more information, see \"[Create a deployment](https://docs.github.com/rest/reference/repos/#create-a-deployment)\" and \"[Create a deployment status](https://docs.github.com/rest/reference/repos#create-a-deployment-status).\"", "tags": [ "repos" ], @@ -57961,7 +57961,7 @@ "categoryLabel": "Deployments", "notes": [], "bodyParameters": [], - "descriptionHTML": "To ensure there can always be an active deployment, you can only delete an inactive deployment. Anyone with repo or repo_deployment scopes can delete an inactive deployment.
To set a deployment as inactive, you must:
\nFor more information, see \"Create a deployment\" and \"Create a deployment status.\"
", + "descriptionHTML": "If the repository only has one deployment, you can delete the deployment regardless of its status. If the repository has more than one deployment, you can only delete inactive deployments. This ensures that repositories with multiple deployments will always have an active deployment. Anyone with repo or repo_deployment scopes can delete a deployment.
To set a deployment as inactive, you must:
\nFor more information, see \"Create a deployment\" and \"Create a deployment status.\"
", "responses": [ { "httpStatusCode": "204", @@ -94180,7 +94180,7 @@ } ], "summary": "Update a codespace for the authenticated user", - "description": "Updates a codespace owned by the authenticated user. Currently only the codespace's machine type can be modified using this endpoint.\n\nOnce you specify a new machine type it will be applied the next time your codespace is started.\n\nYou must authenticate using an access token with the `codespace` scope to use this endpoint.", + "description": "Updates a codespace owned by the authenticated user. Currently only the codespace's machine type and recent folders can be modified using this endpoint.\n\nIf you specify a new machine type it will be applied the next time your codespace is started.\n\nYou must authenticate using an access token with the `codespace` scope to use this endpoint.", "tags": [ "codespaces" ], @@ -94204,6 +94204,18 @@ "rawType": "string", "rawDescription": "A valid machine to transition this codespace to.", "childParamsGroups": [] + }, + "recent_folders": { + "description": "Recently opened folders inside the codespace. It is currently used by the clients to determine the folder path to load the codespace in.
", + "type": "array of strings", + "items": { + "type": "string" + }, + "name": "recent_folders", + "in": "body", + "rawType": "array", + "rawDescription": "Recently opened folders inside the codespace. It is currently used by the clients to determine the folder path to load the codespace in.", + "childParamsGroups": [] } } }, @@ -94224,7 +94236,7 @@ "categoryLabel": "Codespaces", "contentType": "application/json", "notes": [], - "descriptionHTML": "Updates a codespace owned by the authenticated user. Currently only the codespace's machine type can be modified using this endpoint.
\nOnce you specify a new machine type it will be applied the next time your codespace is started.
\nYou must authenticate using an access token with the codespace scope to use this endpoint.
Updates a codespace owned by the authenticated user. Currently only the codespace's machine type and recent folders can be modified using this endpoint.
\nIf you specify a new machine type it will be applied the next time your codespace is started.
\nYou must authenticate using an access token with the codespace scope to use this endpoint.
A valid machine to transition this codespace to.
", @@ -94234,6 +94246,18 @@ "rawType": "string", "rawDescription": "A valid machine to transition this codespace to.", "childParamsGroups": [] + }, + { + "description": "Recently opened folders inside the codespace. It is currently used by the clients to determine the folder path to load the codespace in.
", + "type": "array of strings", + "items": { + "type": "string" + }, + "name": "recent_folders", + "in": "body", + "rawType": "array", + "rawDescription": "Recently opened folders inside the codespace. It is currently used by the clients to determine the folder path to load the codespace in.", + "childParamsGroups": [] } ], "responses": [ diff --git a/lib/rest/static/decorated/ghes-3.0.json b/lib/rest/static/decorated/ghes-3.0.json index d11033cfa6..1672c331d9 100644 --- a/lib/rest/static/decorated/ghes-3.0.json +++ b/lib/rest/static/decorated/ghes-3.0.json @@ -50885,7 +50885,7 @@ } ], "summary": "Create a deployment", - "description": "Deployments offer a few configurable parameters with certain defaults.\n\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.\n\nThe `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`.\n\nThe `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.\n\nBy default, [commit statuses](https://docs.github.com/enterprise-server@3.0/rest/reference/repos#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.\n\nThe `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.\n\nThe `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.\n\nUsers with `repo` or `repo_deployment` scopes can create a deployment for a given ref.\n\n#### 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:\n* Auto-merge option is enabled in the repository\n* Topic branch does not include the latest changes on the base branch, which is `master` in the response example\n* There are no merge conflicts\n\nIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.\n\n#### Merge 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.\n\n#### 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`.", + "description": "Deployments offer a few configurable parameters with certain defaults.\n\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.\n\nThe `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`.\n\nThe `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.\n\nBy default, [commit statuses](https://docs.github.com/enterprise-server@3.0/rest/reference/commits#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.\n\nThe `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.\n\nThe `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.\n\nUsers with `repo` or `repo_deployment` scopes can create a deployment for a given ref.\n\n#### 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:\n* Auto-merge option is enabled in the repository\n* Topic branch does not include the latest changes on the base branch, which is `master` in the response example\n* There are no merge conflicts\n\nIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.\n\n#### Merge 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.\n\n#### 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`.", "tags": [ "repos" ], @@ -50932,14 +50932,14 @@ }, "required_contexts": { "type": "array of strings", - "description": "The status contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.
", + "description": "The status contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.
", "items": { "type": "string" }, "name": "required_contexts", "in": "body", "rawType": "array", - "rawDescription": "The [status](https://docs.github.com/enterprise-server@3.0/rest/reference/repos#statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", + "rawDescription": "The [status](https://docs.github.com/enterprise-server@3.0/rest/reference/commits#commit-statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", "childParamsGroups": [] }, "payload": { @@ -51049,7 +51049,7 @@ "categoryLabel": "Deployments", "contentType": "application/json", "notes": [], - "descriptionHTML": "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.
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.
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.
The status contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.
", + "description": "The status contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.
", "items": { "type": "string" }, "name": "required_contexts", "in": "body", "rawType": "array", - "rawDescription": "The [status](https://docs.github.com/enterprise-server@3.0/rest/reference/repos#statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", + "rawDescription": "The [status](https://docs.github.com/enterprise-server@3.0/rest/reference/commits#commit-statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", "childParamsGroups": [] }, { @@ -51317,7 +51317,7 @@ } ], "summary": "Delete a deployment", - "description": "To ensure there can always be an active deployment, you can only delete an _inactive_ deployment. Anyone with `repo` or `repo_deployment` scopes can delete an inactive deployment.\n\nTo set a deployment as inactive, you must:\n\n* Create a new deployment that is active so that the system has a record of the current state, then delete the previously active deployment.\n* Mark the active deployment as inactive by adding any non-successful deployment status.\n\nFor more information, see \"[Create a deployment](https://docs.github.com/enterprise-server@3.0/rest/reference/repos/#create-a-deployment)\" and \"[Create a deployment status](https://docs.github.com/enterprise-server@3.0/rest/reference/repos#create-a-deployment-status).\"", + "description": "If the repository only has one deployment, you can delete the deployment regardless of its status. If the repository has more than one deployment, you can only delete inactive deployments. This ensures that repositories with multiple deployments will always have an active deployment. Anyone with `repo` or `repo_deployment` scopes can delete a deployment.\n\nTo set a deployment as inactive, you must:\n\n* Create a new deployment that is active so that the system has a record of the current state, then delete the previously active deployment.\n* Mark the active deployment as inactive by adding any non-successful deployment status.\n\nFor more information, see \"[Create a deployment](https://docs.github.com/enterprise-server@3.0/rest/reference/repos/#create-a-deployment)\" and \"[Create a deployment status](https://docs.github.com/enterprise-server@3.0/rest/reference/repos#create-a-deployment-status).\"", "tags": [ "repos" ], @@ -51337,7 +51337,7 @@ "categoryLabel": "Deployments", "notes": [], "bodyParameters": [], - "descriptionHTML": "To ensure there can always be an active deployment, you can only delete an inactive deployment. Anyone with repo or repo_deployment scopes can delete an inactive deployment.
To set a deployment as inactive, you must:
\nFor more information, see \"Create a deployment\" and \"Create a deployment status.\"
", + "descriptionHTML": "If the repository only has one deployment, you can delete the deployment regardless of its status. If the repository has more than one deployment, you can only delete inactive deployments. This ensures that repositories with multiple deployments will always have an active deployment. Anyone with repo or repo_deployment scopes can delete a deployment.
To set a deployment as inactive, you must:
\nFor more information, see \"Create a deployment\" and \"Create a deployment status.\"
", "responses": [ { "httpStatusCode": "204", diff --git a/lib/rest/static/decorated/ghes-3.1.json b/lib/rest/static/decorated/ghes-3.1.json index 3adb46352e..123a9249bf 100644 --- a/lib/rest/static/decorated/ghes-3.1.json +++ b/lib/rest/static/decorated/ghes-3.1.json @@ -51552,7 +51552,7 @@ } ], "summary": "Create a deployment", - "description": "Deployments offer a few configurable parameters with certain defaults.\n\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.\n\nThe `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`.\n\nThe `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.\n\nBy default, [commit statuses](https://docs.github.com/enterprise-server@3.1/rest/reference/repos#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.\n\nThe `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.\n\nThe `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.\n\nUsers with `repo` or `repo_deployment` scopes can create a deployment for a given ref.\n\n#### 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:\n* Auto-merge option is enabled in the repository\n* Topic branch does not include the latest changes on the base branch, which is `master` in the response example\n* There are no merge conflicts\n\nIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.\n\n#### Merge 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.\n\n#### 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`.", + "description": "Deployments offer a few configurable parameters with certain defaults.\n\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.\n\nThe `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`.\n\nThe `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.\n\nBy default, [commit statuses](https://docs.github.com/enterprise-server@3.1/rest/reference/commits#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.\n\nThe `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.\n\nThe `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.\n\nUsers with `repo` or `repo_deployment` scopes can create a deployment for a given ref.\n\n#### 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:\n* Auto-merge option is enabled in the repository\n* Topic branch does not include the latest changes on the base branch, which is `master` in the response example\n* There are no merge conflicts\n\nIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.\n\n#### Merge 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.\n\n#### 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`.", "tags": [ "repos" ], @@ -51599,14 +51599,14 @@ }, "required_contexts": { "type": "array of strings", - "description": "The status contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.
", + "description": "The status contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.
", "items": { "type": "string" }, "name": "required_contexts", "in": "body", "rawType": "array", - "rawDescription": "The [status](https://docs.github.com/enterprise-server@3.1/rest/reference/repos#statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", + "rawDescription": "The [status](https://docs.github.com/enterprise-server@3.1/rest/reference/commits#commit-statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", "childParamsGroups": [] }, "payload": { @@ -51716,7 +51716,7 @@ "categoryLabel": "Deployments", "contentType": "application/json", "notes": [], - "descriptionHTML": "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.
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.
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.
The status contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.
", + "description": "The status contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.
", "items": { "type": "string" }, "name": "required_contexts", "in": "body", "rawType": "array", - "rawDescription": "The [status](https://docs.github.com/enterprise-server@3.1/rest/reference/repos#statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", + "rawDescription": "The [status](https://docs.github.com/enterprise-server@3.1/rest/reference/commits#commit-statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", "childParamsGroups": [] }, { @@ -51984,7 +51984,7 @@ } ], "summary": "Delete a deployment", - "description": "To ensure there can always be an active deployment, you can only delete an _inactive_ deployment. Anyone with `repo` or `repo_deployment` scopes can delete an inactive deployment.\n\nTo set a deployment as inactive, you must:\n\n* Create a new deployment that is active so that the system has a record of the current state, then delete the previously active deployment.\n* Mark the active deployment as inactive by adding any non-successful deployment status.\n\nFor more information, see \"[Create a deployment](https://docs.github.com/enterprise-server@3.1/rest/reference/repos/#create-a-deployment)\" and \"[Create a deployment status](https://docs.github.com/enterprise-server@3.1/rest/reference/repos#create-a-deployment-status).\"", + "description": "If the repository only has one deployment, you can delete the deployment regardless of its status. If the repository has more than one deployment, you can only delete inactive deployments. This ensures that repositories with multiple deployments will always have an active deployment. Anyone with `repo` or `repo_deployment` scopes can delete a deployment.\n\nTo set a deployment as inactive, you must:\n\n* Create a new deployment that is active so that the system has a record of the current state, then delete the previously active deployment.\n* Mark the active deployment as inactive by adding any non-successful deployment status.\n\nFor more information, see \"[Create a deployment](https://docs.github.com/enterprise-server@3.1/rest/reference/repos/#create-a-deployment)\" and \"[Create a deployment status](https://docs.github.com/enterprise-server@3.1/rest/reference/repos#create-a-deployment-status).\"", "tags": [ "repos" ], @@ -52004,7 +52004,7 @@ "categoryLabel": "Deployments", "notes": [], "bodyParameters": [], - "descriptionHTML": "To ensure there can always be an active deployment, you can only delete an inactive deployment. Anyone with repo or repo_deployment scopes can delete an inactive deployment.
To set a deployment as inactive, you must:
\nFor more information, see \"Create a deployment\" and \"Create a deployment status.\"
", + "descriptionHTML": "If the repository only has one deployment, you can delete the deployment regardless of its status. If the repository has more than one deployment, you can only delete inactive deployments. This ensures that repositories with multiple deployments will always have an active deployment. Anyone with repo or repo_deployment scopes can delete a deployment.
To set a deployment as inactive, you must:
\nFor more information, see \"Create a deployment\" and \"Create a deployment status.\"
", "responses": [ { "httpStatusCode": "204", diff --git a/lib/rest/static/decorated/ghes-3.2.json b/lib/rest/static/decorated/ghes-3.2.json index a0c45c8893..b744ed22ea 100644 --- a/lib/rest/static/decorated/ghes-3.2.json +++ b/lib/rest/static/decorated/ghes-3.2.json @@ -52822,7 +52822,7 @@ } ], "summary": "Create a deployment", - "description": "Deployments offer a few configurable parameters with certain defaults.\n\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.\n\nThe `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`.\n\nThe `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.\n\nBy default, [commit statuses](https://docs.github.com/enterprise-server@3.2/rest/reference/repos#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.\n\nThe `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.\n\nThe `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.\n\nUsers with `repo` or `repo_deployment` scopes can create a deployment for a given ref.\n\n#### 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:\n* Auto-merge option is enabled in the repository\n* Topic branch does not include the latest changes on the base branch, which is `master` in the response example\n* There are no merge conflicts\n\nIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.\n\n#### Merge 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.\n\n#### 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`.", + "description": "Deployments offer a few configurable parameters with certain defaults.\n\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.\n\nThe `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`.\n\nThe `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.\n\nBy default, [commit statuses](https://docs.github.com/enterprise-server@3.2/rest/reference/commits#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.\n\nThe `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.\n\nThe `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.\n\nUsers with `repo` or `repo_deployment` scopes can create a deployment for a given ref.\n\n#### 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:\n* Auto-merge option is enabled in the repository\n* Topic branch does not include the latest changes on the base branch, which is `master` in the response example\n* There are no merge conflicts\n\nIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.\n\n#### Merge 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.\n\n#### 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`.", "tags": [ "repos" ], @@ -52869,14 +52869,14 @@ }, "required_contexts": { "type": "array of strings", - "description": "The status contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.
", + "description": "The status contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.
", "items": { "type": "string" }, "name": "required_contexts", "in": "body", "rawType": "array", - "rawDescription": "The [status](https://docs.github.com/enterprise-server@3.2/rest/reference/repos#statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", + "rawDescription": "The [status](https://docs.github.com/enterprise-server@3.2/rest/reference/commits#commit-statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", "childParamsGroups": [] }, "payload": { @@ -52986,7 +52986,7 @@ "categoryLabel": "Deployments", "contentType": "application/json", "notes": [], - "descriptionHTML": "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.
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.
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.
The status contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.
", + "description": "The status contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.
", "items": { "type": "string" }, "name": "required_contexts", "in": "body", "rawType": "array", - "rawDescription": "The [status](https://docs.github.com/enterprise-server@3.2/rest/reference/repos#statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", + "rawDescription": "The [status](https://docs.github.com/enterprise-server@3.2/rest/reference/commits#commit-statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", "childParamsGroups": [] }, { @@ -53254,7 +53254,7 @@ } ], "summary": "Delete a deployment", - "description": "To ensure there can always be an active deployment, you can only delete an _inactive_ deployment. Anyone with `repo` or `repo_deployment` scopes can delete an inactive deployment.\n\nTo set a deployment as inactive, you must:\n\n* Create a new deployment that is active so that the system has a record of the current state, then delete the previously active deployment.\n* Mark the active deployment as inactive by adding any non-successful deployment status.\n\nFor more information, see \"[Create a deployment](https://docs.github.com/enterprise-server@3.2/rest/reference/repos/#create-a-deployment)\" and \"[Create a deployment status](https://docs.github.com/enterprise-server@3.2/rest/reference/repos#create-a-deployment-status).\"", + "description": "If the repository only has one deployment, you can delete the deployment regardless of its status. If the repository has more than one deployment, you can only delete inactive deployments. This ensures that repositories with multiple deployments will always have an active deployment. Anyone with `repo` or `repo_deployment` scopes can delete a deployment.\n\nTo set a deployment as inactive, you must:\n\n* Create a new deployment that is active so that the system has a record of the current state, then delete the previously active deployment.\n* Mark the active deployment as inactive by adding any non-successful deployment status.\n\nFor more information, see \"[Create a deployment](https://docs.github.com/enterprise-server@3.2/rest/reference/repos/#create-a-deployment)\" and \"[Create a deployment status](https://docs.github.com/enterprise-server@3.2/rest/reference/repos#create-a-deployment-status).\"", "tags": [ "repos" ], @@ -53274,7 +53274,7 @@ "categoryLabel": "Deployments", "notes": [], "bodyParameters": [], - "descriptionHTML": "To ensure there can always be an active deployment, you can only delete an inactive deployment. Anyone with repo or repo_deployment scopes can delete an inactive deployment.
To set a deployment as inactive, you must:
\nFor more information, see \"Create a deployment\" and \"Create a deployment status.\"
", + "descriptionHTML": "If the repository only has one deployment, you can delete the deployment regardless of its status. If the repository has more than one deployment, you can only delete inactive deployments. This ensures that repositories with multiple deployments will always have an active deployment. Anyone with repo or repo_deployment scopes can delete a deployment.
To set a deployment as inactive, you must:
\nFor more information, see \"Create a deployment\" and \"Create a deployment status.\"
", "responses": [ { "httpStatusCode": "204", diff --git a/lib/rest/static/decorated/ghes-3.3.json b/lib/rest/static/decorated/ghes-3.3.json index 81136f5167..53aa4f92ff 100644 --- a/lib/rest/static/decorated/ghes-3.3.json +++ b/lib/rest/static/decorated/ghes-3.3.json @@ -53130,7 +53130,7 @@ } ], "summary": "Create a deployment", - "description": "Deployments offer a few configurable parameters with certain defaults.\n\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.\n\nThe `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`.\n\nThe `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.\n\nBy default, [commit statuses](https://docs.github.com/enterprise-server@3.3/rest/reference/repos#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.\n\nThe `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.\n\nThe `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.\n\nUsers with `repo` or `repo_deployment` scopes can create a deployment for a given ref.\n\n#### 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:\n* Auto-merge option is enabled in the repository\n* Topic branch does not include the latest changes on the base branch, which is `master` in the response example\n* There are no merge conflicts\n\nIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.\n\n#### Merge 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.\n\n#### 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`.", + "description": "Deployments offer a few configurable parameters with certain defaults.\n\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.\n\nThe `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`.\n\nThe `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.\n\nBy default, [commit statuses](https://docs.github.com/enterprise-server@3.3/rest/reference/commits#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.\n\nThe `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.\n\nThe `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.\n\nUsers with `repo` or `repo_deployment` scopes can create a deployment for a given ref.\n\n#### 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:\n* Auto-merge option is enabled in the repository\n* Topic branch does not include the latest changes on the base branch, which is `master` in the response example\n* There are no merge conflicts\n\nIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.\n\n#### Merge 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.\n\n#### 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`.", "tags": [ "repos" ], @@ -53177,14 +53177,14 @@ }, "required_contexts": { "type": "array of strings", - "description": "The status contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.
", + "description": "The status contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.
", "items": { "type": "string" }, "name": "required_contexts", "in": "body", "rawType": "array", - "rawDescription": "The [status](https://docs.github.com/enterprise-server@3.3/rest/reference/repos#statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", + "rawDescription": "The [status](https://docs.github.com/enterprise-server@3.3/rest/reference/commits#commit-statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", "childParamsGroups": [] }, "payload": { @@ -53287,7 +53287,7 @@ "categoryLabel": "Deployments", "contentType": "application/json", "notes": [], - "descriptionHTML": "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.
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.
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.
The status contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.
", + "description": "The status contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.
", "items": { "type": "string" }, "name": "required_contexts", "in": "body", "rawType": "array", - "rawDescription": "The [status](https://docs.github.com/enterprise-server@3.3/rest/reference/repos#statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", + "rawDescription": "The [status](https://docs.github.com/enterprise-server@3.3/rest/reference/commits#commit-statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", "childParamsGroups": [] }, { @@ -53543,7 +53543,7 @@ } ], "summary": "Delete a deployment", - "description": "To ensure there can always be an active deployment, you can only delete an _inactive_ deployment. Anyone with `repo` or `repo_deployment` scopes can delete an inactive deployment.\n\nTo set a deployment as inactive, you must:\n\n* Create a new deployment that is active so that the system has a record of the current state, then delete the previously active deployment.\n* Mark the active deployment as inactive by adding any non-successful deployment status.\n\nFor more information, see \"[Create a deployment](https://docs.github.com/enterprise-server@3.3/rest/reference/repos/#create-a-deployment)\" and \"[Create a deployment status](https://docs.github.com/enterprise-server@3.3/rest/reference/repos#create-a-deployment-status).\"", + "description": "If the repository only has one deployment, you can delete the deployment regardless of its status. If the repository has more than one deployment, you can only delete inactive deployments. This ensures that repositories with multiple deployments will always have an active deployment. Anyone with `repo` or `repo_deployment` scopes can delete a deployment.\n\nTo set a deployment as inactive, you must:\n\n* Create a new deployment that is active so that the system has a record of the current state, then delete the previously active deployment.\n* Mark the active deployment as inactive by adding any non-successful deployment status.\n\nFor more information, see \"[Create a deployment](https://docs.github.com/enterprise-server@3.3/rest/reference/repos/#create-a-deployment)\" and \"[Create a deployment status](https://docs.github.com/enterprise-server@3.3/rest/reference/repos#create-a-deployment-status).\"", "tags": [ "repos" ], @@ -53563,7 +53563,7 @@ "categoryLabel": "Deployments", "notes": [], "bodyParameters": [], - "descriptionHTML": "To ensure there can always be an active deployment, you can only delete an inactive deployment. Anyone with repo or repo_deployment scopes can delete an inactive deployment.
To set a deployment as inactive, you must:
\nFor more information, see \"Create a deployment\" and \"Create a deployment status.\"
", + "descriptionHTML": "If the repository only has one deployment, you can delete the deployment regardless of its status. If the repository has more than one deployment, you can only delete inactive deployments. This ensures that repositories with multiple deployments will always have an active deployment. Anyone with repo or repo_deployment scopes can delete a deployment.
To set a deployment as inactive, you must:
\nFor more information, see \"Create a deployment\" and \"Create a deployment status.\"
", "responses": [ { "httpStatusCode": "204", diff --git a/lib/rest/static/decorated/github.ae.json b/lib/rest/static/decorated/github.ae.json index 77e7124a2f..acfed76645 100644 --- a/lib/rest/static/decorated/github.ae.json +++ b/lib/rest/static/decorated/github.ae.json @@ -45681,7 +45681,7 @@ } ], "summary": "Create a deployment", - "description": "Deployments offer a few configurable parameters with certain defaults.\n\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.\n\nThe `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`.\n\nThe `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.\n\nBy default, [commit statuses](https://docs.github.com/github-ae@latest/rest/reference/repos#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.\n\nThe `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.\n\nThe `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.\n\nUsers with `repo` or `repo_deployment` scopes can create a deployment for a given ref.\n\n#### 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:\n* Auto-merge option is enabled in the repository\n* Topic branch does not include the latest changes on the base branch, which is `master` in the response example\n* There are no merge conflicts\n\nIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.\n\n#### Merge 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.\n\n#### 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`.", + "description": "Deployments offer a few configurable parameters with certain defaults.\n\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.\n\nThe `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`.\n\nThe `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.\n\nBy default, [commit statuses](https://docs.github.com/github-ae@latest/rest/reference/commits#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.\n\nThe `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.\n\nThe `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.\n\nUsers with `repo` or `repo_deployment` scopes can create a deployment for a given ref.\n\n#### 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:\n* Auto-merge option is enabled in the repository\n* Topic branch does not include the latest changes on the base branch, which is `master` in the response example\n* There are no merge conflicts\n\nIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.\n\n#### Merge 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.\n\n#### 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`.", "tags": [ "repos" ], @@ -45728,14 +45728,14 @@ }, "required_contexts": { "type": "array of strings", - "description": "The status contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.
", + "description": "The status contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.
", "items": { "type": "string" }, "name": "required_contexts", "in": "body", "rawType": "array", - "rawDescription": "The [status](https://docs.github.com/github-ae@latest/rest/reference/repos#statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", + "rawDescription": "The [status](https://docs.github.com/github-ae@latest/rest/reference/commits#commit-statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", "childParamsGroups": [] }, "payload": { @@ -45838,7 +45838,7 @@ "categoryLabel": "Deployments", "contentType": "application/json", "notes": [], - "descriptionHTML": "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.
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.
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.
The status contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.
", + "description": "The status contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.
", "items": { "type": "string" }, "name": "required_contexts", "in": "body", "rawType": "array", - "rawDescription": "The [status](https://docs.github.com/github-ae@latest/rest/reference/repos#statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", + "rawDescription": "The [status](https://docs.github.com/github-ae@latest/rest/reference/commits#commit-statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", "childParamsGroups": [] }, { @@ -46094,7 +46094,7 @@ } ], "summary": "Delete a deployment", - "description": "To ensure there can always be an active deployment, you can only delete an _inactive_ deployment. Anyone with `repo` or `repo_deployment` scopes can delete an inactive deployment.\n\nTo set a deployment as inactive, you must:\n\n* Create a new deployment that is active so that the system has a record of the current state, then delete the previously active deployment.\n* Mark the active deployment as inactive by adding any non-successful deployment status.\n\nFor more information, see \"[Create a deployment](https://docs.github.com/github-ae@latest/rest/reference/repos/#create-a-deployment)\" and \"[Create a deployment status](https://docs.github.com/github-ae@latest/rest/reference/repos#create-a-deployment-status).\"", + "description": "If the repository only has one deployment, you can delete the deployment regardless of its status. If the repository has more than one deployment, you can only delete inactive deployments. This ensures that repositories with multiple deployments will always have an active deployment. Anyone with `repo` or `repo_deployment` scopes can delete a deployment.\n\nTo set a deployment as inactive, you must:\n\n* Create a new deployment that is active so that the system has a record of the current state, then delete the previously active deployment.\n* Mark the active deployment as inactive by adding any non-successful deployment status.\n\nFor more information, see \"[Create a deployment](https://docs.github.com/github-ae@latest/rest/reference/repos/#create-a-deployment)\" and \"[Create a deployment status](https://docs.github.com/github-ae@latest/rest/reference/repos#create-a-deployment-status).\"", "tags": [ "repos" ], @@ -46114,7 +46114,7 @@ "categoryLabel": "Deployments", "notes": [], "bodyParameters": [], - "descriptionHTML": "To ensure there can always be an active deployment, you can only delete an inactive deployment. Anyone with repo or repo_deployment scopes can delete an inactive deployment.
To set a deployment as inactive, you must:
\nFor more information, see \"Create a deployment\" and \"Create a deployment status.\"
", + "descriptionHTML": "If the repository only has one deployment, you can delete the deployment regardless of its status. If the repository has more than one deployment, you can only delete inactive deployments. This ensures that repositories with multiple deployments will always have an active deployment. Anyone with repo or repo_deployment scopes can delete a deployment.
To set a deployment as inactive, you must:
\nFor more information, see \"Create a deployment\" and \"Create a deployment status.\"
", "responses": [ { "httpStatusCode": "204", diff --git a/lib/rest/static/dereferenced/api.github.com.deref.json b/lib/rest/static/dereferenced/api.github.com.deref.json index 02ff05a921..29281f3243 100644 --- a/lib/rest/static/dereferenced/api.github.com.deref.json +++ b/lib/rest/static/dereferenced/api.github.com.deref.json @@ -223065,7 +223065,7 @@ }, "post": { "summary": "Create a deployment", - "description": "Deployments offer a few configurable parameters with certain defaults.\n\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.\n\nThe `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`.\n\nThe `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.\n\nBy default, [commit statuses](https://docs.github.com/rest/reference/repos#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.\n\nThe `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.\n\nThe `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.\n\nUsers with `repo` or `repo_deployment` scopes can create a deployment for a given ref.\n\n#### 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:\n* Auto-merge option is enabled in the repository\n* Topic branch does not include the latest changes on the base branch, which is `master` in the response example\n* There are no merge conflicts\n\nIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.\n\n#### Merge 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.\n\n#### 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`.", + "description": "Deployments offer a few configurable parameters with certain defaults.\n\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.\n\nThe `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`.\n\nThe `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.\n\nBy default, [commit statuses](https://docs.github.com/rest/reference/commits#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.\n\nThe `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.\n\nThe `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.\n\nUsers with `repo` or `repo_deployment` scopes can create a deployment for a given ref.\n\n#### 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:\n* Auto-merge option is enabled in the repository\n* Topic branch does not include the latest changes on the base branch, which is `master` in the response example\n* There are no merge conflicts\n\nIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.\n\n#### Merge 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.\n\n#### 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`.", "tags": [ "repos" ], @@ -223115,7 +223115,7 @@ }, "required_contexts": { "type": "array", - "description": "The [status](https://docs.github.com/rest/reference/repos#statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", + "description": "The [status](https://docs.github.com/rest/reference/commits#commit-statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", "items": { "type": "string" } @@ -224409,7 +224409,7 @@ }, "delete": { "summary": "Delete a deployment", - "description": "To ensure there can always be an active deployment, you can only delete an _inactive_ deployment. Anyone with `repo` or `repo_deployment` scopes can delete an inactive deployment.\n\nTo set a deployment as inactive, you must:\n\n* Create a new deployment that is active so that the system has a record of the current state, then delete the previously active deployment.\n* Mark the active deployment as inactive by adding any non-successful deployment status.\n\nFor more information, see \"[Create a deployment](https://docs.github.com/rest/reference/repos/#create-a-deployment)\" and \"[Create a deployment status](https://docs.github.com/rest/reference/repos#create-a-deployment-status).\"", + "description": "If the repository only has one deployment, you can delete the deployment regardless of its status. If the repository has more than one deployment, you can only delete inactive deployments. This ensures that repositories with multiple deployments will always have an active deployment. Anyone with `repo` or `repo_deployment` scopes can delete a deployment.\n\nTo set a deployment as inactive, you must:\n\n* Create a new deployment that is active so that the system has a record of the current state, then delete the previously active deployment.\n* Mark the active deployment as inactive by adding any non-successful deployment status.\n\nFor more information, see \"[Create a deployment](https://docs.github.com/rest/reference/repos/#create-a-deployment)\" and \"[Create a deployment status](https://docs.github.com/rest/reference/repos#create-a-deployment-status).\"", "tags": [ "repos" ], @@ -408573,7 +408573,7 @@ }, "patch": { "summary": "Update a codespace for the authenticated user", - "description": "Updates a codespace owned by the authenticated user. Currently only the codespace's machine type can be modified using this endpoint.\n\nOnce you specify a new machine type it will be applied the next time your codespace is started.\n\nYou must authenticate using an access token with the `codespace` scope to use this endpoint.", + "description": "Updates a codespace owned by the authenticated user. Currently only the codespace's machine type and recent folders can be modified using this endpoint.\n\nIf you specify a new machine type it will be applied the next time your codespace is started.\n\nYou must authenticate using an access token with the `codespace` scope to use this endpoint.", "tags": [ "codespaces" ], @@ -408603,6 +408603,13 @@ "machine": { "description": "A valid machine to transition this codespace to.", "type": "string" + }, + "recent_folders": { + "description": "Recently opened folders inside the codespace. It is currently used by the clients to determine the folder path to load the codespace in.", + "type": "array", + "items": { + "type": "string" + } } } }, diff --git a/lib/rest/static/dereferenced/ghes-3.0.deref.json b/lib/rest/static/dereferenced/ghes-3.0.deref.json index 8abfabcccb..4241219ded 100644 --- a/lib/rest/static/dereferenced/ghes-3.0.deref.json +++ b/lib/rest/static/dereferenced/ghes-3.0.deref.json @@ -179984,7 +179984,7 @@ }, "post": { "summary": "Create a deployment", - "description": "Deployments offer a few configurable parameters with certain defaults.\n\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.\n\nThe `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`.\n\nThe `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.\n\nBy default, [commit statuses](https://docs.github.com/enterprise-server@3.0/rest/reference/repos#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.\n\nThe `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.\n\nThe `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.\n\nUsers with `repo` or `repo_deployment` scopes can create a deployment for a given ref.\n\n#### 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:\n* Auto-merge option is enabled in the repository\n* Topic branch does not include the latest changes on the base branch, which is `master` in the response example\n* There are no merge conflicts\n\nIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.\n\n#### Merge 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.\n\n#### 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`.", + "description": "Deployments offer a few configurable parameters with certain defaults.\n\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.\n\nThe `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`.\n\nThe `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.\n\nBy default, [commit statuses](https://docs.github.com/enterprise-server@3.0/rest/reference/commits#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.\n\nThe `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.\n\nThe `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.\n\nUsers with `repo` or `repo_deployment` scopes can create a deployment for a given ref.\n\n#### 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:\n* Auto-merge option is enabled in the repository\n* Topic branch does not include the latest changes on the base branch, which is `master` in the response example\n* There are no merge conflicts\n\nIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.\n\n#### Merge 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.\n\n#### 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`.", "tags": [ "repos" ], @@ -180034,7 +180034,7 @@ }, "required_contexts": { "type": "array", - "description": "The [status](https://docs.github.com/enterprise-server@3.0/rest/reference/repos#statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", + "description": "The [status](https://docs.github.com/enterprise-server@3.0/rest/reference/commits#commit-statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", "items": { "type": "string" } @@ -181344,7 +181344,7 @@ }, "delete": { "summary": "Delete a deployment", - "description": "To ensure there can always be an active deployment, you can only delete an _inactive_ deployment. Anyone with `repo` or `repo_deployment` scopes can delete an inactive deployment.\n\nTo set a deployment as inactive, you must:\n\n* Create a new deployment that is active so that the system has a record of the current state, then delete the previously active deployment.\n* Mark the active deployment as inactive by adding any non-successful deployment status.\n\nFor more information, see \"[Create a deployment](https://docs.github.com/enterprise-server@3.0/rest/reference/repos/#create-a-deployment)\" and \"[Create a deployment status](https://docs.github.com/enterprise-server@3.0/rest/reference/repos#create-a-deployment-status).\"", + "description": "If the repository only has one deployment, you can delete the deployment regardless of its status. If the repository has more than one deployment, you can only delete inactive deployments. This ensures that repositories with multiple deployments will always have an active deployment. Anyone with `repo` or `repo_deployment` scopes can delete a deployment.\n\nTo set a deployment as inactive, you must:\n\n* Create a new deployment that is active so that the system has a record of the current state, then delete the previously active deployment.\n* Mark the active deployment as inactive by adding any non-successful deployment status.\n\nFor more information, see \"[Create a deployment](https://docs.github.com/enterprise-server@3.0/rest/reference/repos/#create-a-deployment)\" and \"[Create a deployment status](https://docs.github.com/enterprise-server@3.0/rest/reference/repos#create-a-deployment-status).\"", "tags": [ "repos" ], diff --git a/lib/rest/static/dereferenced/ghes-3.1.deref.json b/lib/rest/static/dereferenced/ghes-3.1.deref.json index c7c2038031..b6e0899ff3 100644 --- a/lib/rest/static/dereferenced/ghes-3.1.deref.json +++ b/lib/rest/static/dereferenced/ghes-3.1.deref.json @@ -182973,7 +182973,7 @@ }, "post": { "summary": "Create a deployment", - "description": "Deployments offer a few configurable parameters with certain defaults.\n\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.\n\nThe `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`.\n\nThe `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.\n\nBy default, [commit statuses](https://docs.github.com/enterprise-server@3.1/rest/reference/repos#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.\n\nThe `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.\n\nThe `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.\n\nUsers with `repo` or `repo_deployment` scopes can create a deployment for a given ref.\n\n#### 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:\n* Auto-merge option is enabled in the repository\n* Topic branch does not include the latest changes on the base branch, which is `master` in the response example\n* There are no merge conflicts\n\nIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.\n\n#### Merge 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.\n\n#### 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`.", + "description": "Deployments offer a few configurable parameters with certain defaults.\n\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.\n\nThe `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`.\n\nThe `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.\n\nBy default, [commit statuses](https://docs.github.com/enterprise-server@3.1/rest/reference/commits#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.\n\nThe `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.\n\nThe `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.\n\nUsers with `repo` or `repo_deployment` scopes can create a deployment for a given ref.\n\n#### 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:\n* Auto-merge option is enabled in the repository\n* Topic branch does not include the latest changes on the base branch, which is `master` in the response example\n* There are no merge conflicts\n\nIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.\n\n#### Merge 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.\n\n#### 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`.", "tags": [ "repos" ], @@ -183023,7 +183023,7 @@ }, "required_contexts": { "type": "array", - "description": "The [status](https://docs.github.com/enterprise-server@3.1/rest/reference/repos#statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", + "description": "The [status](https://docs.github.com/enterprise-server@3.1/rest/reference/commits#commit-statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", "items": { "type": "string" } @@ -184333,7 +184333,7 @@ }, "delete": { "summary": "Delete a deployment", - "description": "To ensure there can always be an active deployment, you can only delete an _inactive_ deployment. Anyone with `repo` or `repo_deployment` scopes can delete an inactive deployment.\n\nTo set a deployment as inactive, you must:\n\n* Create a new deployment that is active so that the system has a record of the current state, then delete the previously active deployment.\n* Mark the active deployment as inactive by adding any non-successful deployment status.\n\nFor more information, see \"[Create a deployment](https://docs.github.com/enterprise-server@3.1/rest/reference/repos/#create-a-deployment)\" and \"[Create a deployment status](https://docs.github.com/enterprise-server@3.1/rest/reference/repos#create-a-deployment-status).\"", + "description": "If the repository only has one deployment, you can delete the deployment regardless of its status. If the repository has more than one deployment, you can only delete inactive deployments. This ensures that repositories with multiple deployments will always have an active deployment. Anyone with `repo` or `repo_deployment` scopes can delete a deployment.\n\nTo set a deployment as inactive, you must:\n\n* Create a new deployment that is active so that the system has a record of the current state, then delete the previously active deployment.\n* Mark the active deployment as inactive by adding any non-successful deployment status.\n\nFor more information, see \"[Create a deployment](https://docs.github.com/enterprise-server@3.1/rest/reference/repos/#create-a-deployment)\" and \"[Create a deployment status](https://docs.github.com/enterprise-server@3.1/rest/reference/repos#create-a-deployment-status).\"", "tags": [ "repos" ], diff --git a/lib/rest/static/dereferenced/ghes-3.2.deref.json b/lib/rest/static/dereferenced/ghes-3.2.deref.json index e04292b656..618bc83aeb 100644 --- a/lib/rest/static/dereferenced/ghes-3.2.deref.json +++ b/lib/rest/static/dereferenced/ghes-3.2.deref.json @@ -186729,7 +186729,7 @@ }, "post": { "summary": "Create a deployment", - "description": "Deployments offer a few configurable parameters with certain defaults.\n\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.\n\nThe `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`.\n\nThe `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.\n\nBy default, [commit statuses](https://docs.github.com/enterprise-server@3.2/rest/reference/repos#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.\n\nThe `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.\n\nThe `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.\n\nUsers with `repo` or `repo_deployment` scopes can create a deployment for a given ref.\n\n#### 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:\n* Auto-merge option is enabled in the repository\n* Topic branch does not include the latest changes on the base branch, which is `master` in the response example\n* There are no merge conflicts\n\nIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.\n\n#### Merge 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.\n\n#### 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`.", + "description": "Deployments offer a few configurable parameters with certain defaults.\n\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.\n\nThe `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`.\n\nThe `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.\n\nBy default, [commit statuses](https://docs.github.com/enterprise-server@3.2/rest/reference/commits#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.\n\nThe `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.\n\nThe `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.\n\nUsers with `repo` or `repo_deployment` scopes can create a deployment for a given ref.\n\n#### 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:\n* Auto-merge option is enabled in the repository\n* Topic branch does not include the latest changes on the base branch, which is `master` in the response example\n* There are no merge conflicts\n\nIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.\n\n#### Merge 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.\n\n#### 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`.", "tags": [ "repos" ], @@ -186779,7 +186779,7 @@ }, "required_contexts": { "type": "array", - "description": "The [status](https://docs.github.com/enterprise-server@3.2/rest/reference/repos#statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", + "description": "The [status](https://docs.github.com/enterprise-server@3.2/rest/reference/commits#commit-statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", "items": { "type": "string" } @@ -188089,7 +188089,7 @@ }, "delete": { "summary": "Delete a deployment", - "description": "To ensure there can always be an active deployment, you can only delete an _inactive_ deployment. Anyone with `repo` or `repo_deployment` scopes can delete an inactive deployment.\n\nTo set a deployment as inactive, you must:\n\n* Create a new deployment that is active so that the system has a record of the current state, then delete the previously active deployment.\n* Mark the active deployment as inactive by adding any non-successful deployment status.\n\nFor more information, see \"[Create a deployment](https://docs.github.com/enterprise-server@3.2/rest/reference/repos/#create-a-deployment)\" and \"[Create a deployment status](https://docs.github.com/enterprise-server@3.2/rest/reference/repos#create-a-deployment-status).\"", + "description": "If the repository only has one deployment, you can delete the deployment regardless of its status. If the repository has more than one deployment, you can only delete inactive deployments. This ensures that repositories with multiple deployments will always have an active deployment. Anyone with `repo` or `repo_deployment` scopes can delete a deployment.\n\nTo set a deployment as inactive, you must:\n\n* Create a new deployment that is active so that the system has a record of the current state, then delete the previously active deployment.\n* Mark the active deployment as inactive by adding any non-successful deployment status.\n\nFor more information, see \"[Create a deployment](https://docs.github.com/enterprise-server@3.2/rest/reference/repos/#create-a-deployment)\" and \"[Create a deployment status](https://docs.github.com/enterprise-server@3.2/rest/reference/repos#create-a-deployment-status).\"", "tags": [ "repos" ], diff --git a/lib/rest/static/dereferenced/ghes-3.3.deref.json b/lib/rest/static/dereferenced/ghes-3.3.deref.json index 6f085c4d09..374449cc31 100644 --- a/lib/rest/static/dereferenced/ghes-3.3.deref.json +++ b/lib/rest/static/dereferenced/ghes-3.3.deref.json @@ -193740,7 +193740,7 @@ }, "post": { "summary": "Create a deployment", - "description": "Deployments offer a few configurable parameters with certain defaults.\n\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.\n\nThe `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`.\n\nThe `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.\n\nBy default, [commit statuses](https://docs.github.com/enterprise-server@3.3/rest/reference/repos#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.\n\nThe `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.\n\nThe `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.\n\nUsers with `repo` or `repo_deployment` scopes can create a deployment for a given ref.\n\n#### 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:\n* Auto-merge option is enabled in the repository\n* Topic branch does not include the latest changes on the base branch, which is `master` in the response example\n* There are no merge conflicts\n\nIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.\n\n#### Merge 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.\n\n#### 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`.", + "description": "Deployments offer a few configurable parameters with certain defaults.\n\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.\n\nThe `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`.\n\nThe `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.\n\nBy default, [commit statuses](https://docs.github.com/enterprise-server@3.3/rest/reference/commits#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.\n\nThe `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.\n\nThe `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.\n\nUsers with `repo` or `repo_deployment` scopes can create a deployment for a given ref.\n\n#### 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:\n* Auto-merge option is enabled in the repository\n* Topic branch does not include the latest changes on the base branch, which is `master` in the response example\n* There are no merge conflicts\n\nIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.\n\n#### Merge 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.\n\n#### 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`.", "tags": [ "repos" ], @@ -193790,7 +193790,7 @@ }, "required_contexts": { "type": "array", - "description": "The [status](https://docs.github.com/enterprise-server@3.3/rest/reference/repos#statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", + "description": "The [status](https://docs.github.com/enterprise-server@3.3/rest/reference/commits#commit-statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", "items": { "type": "string" } @@ -195084,7 +195084,7 @@ }, "delete": { "summary": "Delete a deployment", - "description": "To ensure there can always be an active deployment, you can only delete an _inactive_ deployment. Anyone with `repo` or `repo_deployment` scopes can delete an inactive deployment.\n\nTo set a deployment as inactive, you must:\n\n* Create a new deployment that is active so that the system has a record of the current state, then delete the previously active deployment.\n* Mark the active deployment as inactive by adding any non-successful deployment status.\n\nFor more information, see \"[Create a deployment](https://docs.github.com/enterprise-server@3.3/rest/reference/repos/#create-a-deployment)\" and \"[Create a deployment status](https://docs.github.com/enterprise-server@3.3/rest/reference/repos#create-a-deployment-status).\"", + "description": "If the repository only has one deployment, you can delete the deployment regardless of its status. If the repository has more than one deployment, you can only delete inactive deployments. This ensures that repositories with multiple deployments will always have an active deployment. Anyone with `repo` or `repo_deployment` scopes can delete a deployment.\n\nTo set a deployment as inactive, you must:\n\n* Create a new deployment that is active so that the system has a record of the current state, then delete the previously active deployment.\n* Mark the active deployment as inactive by adding any non-successful deployment status.\n\nFor more information, see \"[Create a deployment](https://docs.github.com/enterprise-server@3.3/rest/reference/repos/#create-a-deployment)\" and \"[Create a deployment status](https://docs.github.com/enterprise-server@3.3/rest/reference/repos#create-a-deployment-status).\"", "tags": [ "repos" ], diff --git a/lib/rest/static/dereferenced/github.ae.deref.json b/lib/rest/static/dereferenced/github.ae.deref.json index a63ed2f839..30389d0690 100644 --- a/lib/rest/static/dereferenced/github.ae.deref.json +++ b/lib/rest/static/dereferenced/github.ae.deref.json @@ -157785,7 +157785,7 @@ }, "post": { "summary": "Create a deployment", - "description": "Deployments offer a few configurable parameters with certain defaults.\n\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.\n\nThe `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`.\n\nThe `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.\n\nBy default, [commit statuses](https://docs.github.com/github-ae@latest/rest/reference/repos#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.\n\nThe `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.\n\nThe `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.\n\nUsers with `repo` or `repo_deployment` scopes can create a deployment for a given ref.\n\n#### 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:\n* Auto-merge option is enabled in the repository\n* Topic branch does not include the latest changes on the base branch, which is `master` in the response example\n* There are no merge conflicts\n\nIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.\n\n#### Merge 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.\n\n#### 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`.", + "description": "Deployments offer a few configurable parameters with certain defaults.\n\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.\n\nThe `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`.\n\nThe `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.\n\nBy default, [commit statuses](https://docs.github.com/github-ae@latest/rest/reference/commits#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.\n\nThe `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.\n\nThe `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.\n\nUsers with `repo` or `repo_deployment` scopes can create a deployment for a given ref.\n\n#### 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:\n* Auto-merge option is enabled in the repository\n* Topic branch does not include the latest changes on the base branch, which is `master` in the response example\n* There are no merge conflicts\n\nIf there are no new commits in the base branch, a new request to create a deployment should give a successful\nresponse.\n\n#### Merge 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.\n\n#### 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`.", "tags": [ "repos" ], @@ -157835,7 +157835,7 @@ }, "required_contexts": { "type": "array", - "description": "The [status](https://docs.github.com/github-ae@latest/rest/reference/repos#statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", + "description": "The [status](https://docs.github.com/github-ae@latest/rest/reference/commits#commit-statuses) contexts to verify against commit status checks. If you omit this parameter, GitHub verifies all unique contexts before creating a deployment. To bypass checking entirely, pass an empty array. Defaults to all unique contexts.", "items": { "type": "string" } @@ -159129,7 +159129,7 @@ }, "delete": { "summary": "Delete a deployment", - "description": "To ensure there can always be an active deployment, you can only delete an _inactive_ deployment. Anyone with `repo` or `repo_deployment` scopes can delete an inactive deployment.\n\nTo set a deployment as inactive, you must:\n\n* Create a new deployment that is active so that the system has a record of the current state, then delete the previously active deployment.\n* Mark the active deployment as inactive by adding any non-successful deployment status.\n\nFor more information, see \"[Create a deployment](https://docs.github.com/github-ae@latest/rest/reference/repos/#create-a-deployment)\" and \"[Create a deployment status](https://docs.github.com/github-ae@latest/rest/reference/repos#create-a-deployment-status).\"", + "description": "If the repository only has one deployment, you can delete the deployment regardless of its status. If the repository has more than one deployment, you can only delete inactive deployments. This ensures that repositories with multiple deployments will always have an active deployment. Anyone with `repo` or `repo_deployment` scopes can delete a deployment.\n\nTo set a deployment as inactive, you must:\n\n* Create a new deployment that is active so that the system has a record of the current state, then delete the previously active deployment.\n* Mark the active deployment as inactive by adding any non-successful deployment status.\n\nFor more information, see \"[Create a deployment](https://docs.github.com/github-ae@latest/rest/reference/repos/#create-a-deployment)\" and \"[Create a deployment status](https://docs.github.com/github-ae@latest/rest/reference/repos#create-a-deployment-status).\"", "tags": [ "repos" ],