diff --git a/docs/repos/createDeployment.md b/docs/repos/createDeployment.md index 3b76d722b..d723bbe3a 100644 --- a/docs/repos/createDeployment.md +++ b/docs/repos/createDeployment.md @@ -23,7 +23,7 @@ A more advanced example specifying required commit statuses and bypassing auto-m You will see this response when GitHub automatically merges the base branch into the topic branch instead of creating a deployment. This auto-merge happens when: - Auto-merge option is enabled in the repository -- Topic branch does not include the latest changes on the base branch, which is `master`in the response example +- Topic branch does not include the latest changes on the base branch, which is `master` in the response example - There are no merge conflicts If there are no new commits in the base branch, a new request to create a deployment should give a successful response. diff --git a/docs/repos/deleteDeployment.md b/docs/repos/deleteDeployment.md new file mode 100644 index 000000000..c9c4558aa --- /dev/null +++ b/docs/repos/deleteDeployment.md @@ -0,0 +1,49 @@ +# Delete a deployment + +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: + +- Create a new deployment that is active so that the system has a record of the current state, then delete the previously active deployment. +- Mark the active deployment as inactive by adding any non-successful deployment status. + +For more information, see "[Create a deployment](https://developer.github.com/v3/repos/deployments/#create-a-deployment)" and "[Create a deployment status](https://developer.github.com/v3/repos/deployments/#create-a-deployment-status)." + +```js +octokit.repos.deleteDeployment({ + owner, + repo, + deployment_id +}); +``` + +## Parameters + + + + + + + + + + + + + + +
namerequireddescription
owneryes + +owner parameter + +
repoyes + +repo parameter + +
deployment_idyes + +deployment_id parameter + +
+ +See also: [GitHub Developer Guide documentation](endpoint.documentationUrl). diff --git a/scripts/update-endpoints/generated/endpoints.json b/scripts/update-endpoints/generated/endpoints.json index f7eee7ec8..463aea8c9 100644 --- a/scripts/update-endpoints/generated/endpoints.json +++ b/scripts/update-endpoints/generated/endpoints.json @@ -20002,7 +20002,7 @@ "url": "/repos/{owner}/{repo}/deployments", "isDeprecated": false, "isLegacy": false, - "description": "Deployments offer a few configurable parameters with sane defaults.\n\nThe `ref` parameter can be any named branch, tag, or SHA. At GitHub we often deploy branches and verify them before we merge a pull request.\n\nThe `environment` parameter allows deployments to be issued to different runtime environments. Teams often have multiple environments for verifying their applications, such as `production`, `staging`, and `qa`. This parameter makes 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 the ref _is_ behind the default branch for the repository, we will attempt to merge it for you. If the merge succeeds, the API will return a successful merge commit. If merge conflicts prevent the merge from succeeding, the API will return a failure response.\n\nBy default, [commit statuses](https://developer.github.com/v3/repos/statuses) for every submitted context must be in a `success` state. The `required_contexts` parameter allows you to specify a subset of contexts that must be `success`, or to specify contexts that have not yet been submitted. You are not required to use commit statuses to deploy. If you do not 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 field 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 be `deploy:migrations` to run schema changes on the system. In the compiled world this could be a flag to compile an application with debugging enabled.\n\nUsers with `repo` or `repo_deployment` scopes can create a deployment for a given ref:\n\nA simple example putting the user and room into the payload to notify back to chat networks.\n\nA more advanced example specifying required commit statuses and bypassing auto-merging.\n\nYou will see this response when GitHub automatically merges the base branch into the topic branch instead of creating a deployment. This auto-merge happens when:\n\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 response.\n\nThis error happens when the `auto_merge` option is enabled and when the default branch (in this case `master`), can't be merged into the branch that's being deployed (in this case `topic-branch`), due to merge conflicts.\n\nThis error happens when the `required_contexts` parameter indicates that one or more contexts need to have a `success` status 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 sane defaults.\n\nThe `ref` parameter can be any named branch, tag, or SHA. At GitHub we often deploy branches and verify them before we merge a pull request.\n\nThe `environment` parameter allows deployments to be issued to different runtime environments. Teams often have multiple environments for verifying their applications, such as `production`, `staging`, and `qa`. This parameter makes 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 the ref _is_ behind the default branch for the repository, we will attempt to merge it for you. If the merge succeeds, the API will return a successful merge commit. If merge conflicts prevent the merge from succeeding, the API will return a failure response.\n\nBy default, [commit statuses](https://developer.github.com/v3/repos/statuses) for every submitted context must be in a `success` state. The `required_contexts` parameter allows you to specify a subset of contexts that must be `success`, or to specify contexts that have not yet been submitted. You are not required to use commit statuses to deploy. If you do not 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 field 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 be `deploy:migrations` to run schema changes on the system. In the compiled world this could be a flag to compile an application with debugging enabled.\n\nUsers with `repo` or `repo_deployment` scopes can create a deployment for a given ref:\n\nA simple example putting the user and room into the payload to notify back to chat networks.\n\nA more advanced example specifying required commit statuses and bypassing auto-merging.\n\nYou will see this response when GitHub automatically merges the base branch into the topic branch instead of creating a deployment. This auto-merge happens when:\n\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 response.\n\nThis error happens when the `auto_merge` option is enabled and when the default branch (in this case `master`), can't be merged into the branch that's being deployed (in this case `topic-branch`), due to merge conflicts.\n\nThis error happens when the `required_contexts` parameter indicates that one or more contexts need to have a `success` status for the commit to be deployed, but one or more of the required contexts do not have a state of `success`.", "documentationUrl": "https://developer.github.com/v3/repos/deployments/#create-a-deployment", "previews": [], "headers": [], @@ -20254,6 +20254,62 @@ ], "renamed": null }, + { + "name": "Delete a deployment", + "scope": "repos", + "id": "deleteDeployment", + "method": "DELETE", + "url": "/repos/{owner}/{repo}/deployments/{deployment_id}", + "isDeprecated": false, + "isLegacy": false, + "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://developer.github.com/v3/repos/deployments/#create-a-deployment)\" and \"[Create a deployment status](https://developer.github.com/v3/repos/deployments/#create-a-deployment-status).\"", + "documentationUrl": "https://developer.github.com/v3/repos/deployments/#delete-a-deployment", + "previews": [], + "headers": [], + "parameters": [ + { + "name": "owner", + "description": "owner parameter", + "in": "PATH", + "type": "string", + "required": true, + "enum": null, + "allowNull": false, + "mapToData": null, + "validation": null, + "alias": null, + "deprecated": null + }, + { + "name": "repo", + "description": "repo parameter", + "in": "PATH", + "type": "string", + "required": true, + "enum": null, + "allowNull": false, + "mapToData": null, + "validation": null, + "alias": null, + "deprecated": null + }, + { + "name": "deployment_id", + "description": "deployment_id parameter", + "in": "PATH", + "type": "integer", + "required": true, + "enum": null, + "allowNull": false, + "mapToData": null, + "validation": null, + "alias": null, + "deprecated": null + } + ], + "responses": [], + "renamed": null + }, { "name": "List deployment statuses", "scope": "repos", diff --git a/src/generated/endpoints.ts b/src/generated/endpoints.ts index da8d51cb9..a53da8b99 100644 --- a/src/generated/endpoints.ts +++ b/src/generated/endpoints.ts @@ -780,6 +780,9 @@ const Endpoints: EndpointsDefaultsAndDecorations = { declineInvitation: ["DELETE /user/repository_invitations/{invitation_id}"], delete: ["DELETE /repos/{owner}/{repo}"], deleteCommitComment: ["DELETE /repos/{owner}/{repo}/comments/{comment_id}"], + deleteDeployment: [ + "DELETE /repos/{owner}/{repo}/deployments/{deployment_id}" + ], deleteDownload: ["DELETE /repos/{owner}/{repo}/downloads/{download_id}"], deleteFile: ["DELETE /repos/{owner}/{repo}/contents/{path}"], deleteHook: ["DELETE /repos/{owner}/{repo}/hooks/{hook_id}"], diff --git a/src/generated/types.ts b/src/generated/types.ts index b8b978aca..3dd9a0945 100644 --- a/src/generated/types.ts +++ b/src/generated/types.ts @@ -24928,6 +24928,11 @@ export type ReposDeleteCommitCommentParams = { owner: string; repo: string; }; +export type ReposDeleteDeploymentParams = { + deployment_id: number; + owner: string; + repo: string; +}; export type ReposDeleteDownloadParams = { download_id: number; owner: string; @@ -31088,7 +31093,7 @@ export type RestEndpointMethods = { * You will see this response when GitHub automatically merges the base branch into the topic branch instead of creating a deployment. This auto-merge happens when: * * * Auto-merge option is enabled in the repository - * * Topic branch does not include the latest changes on the base branch, which is `master`in the response example + * * Topic branch does not include the latest changes on the base branch, which is `master` in the response example * * There are no merge conflicts * * If there are no new commits in the base branch, a new request to create a deployment should give a successful response. @@ -31271,6 +31276,23 @@ export type RestEndpointMethods = { endpoint: EndpointInterface; }; + /** + * 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: + * + * * Create a new deployment that is active so that the system has a record of the current state, then delete the previously active deployment. + * * Mark the active deployment as inactive by adding any non-successful deployment status. + * + * For more information, see "[Create a deployment](https://developer.github.com/v3/repos/deployments/#create-a-deployment)" and "[Create a deployment status](https://developer.github.com/v3/repos/deployments/#create-a-deployment-status)." + */ + deleteDeployment: { + (params?: RequestParameters & ReposDeleteDeploymentParams): Promise< + AnyResponse + >; + + endpoint: EndpointInterface; + }; deleteDownload: { (params?: RequestParameters & ReposDeleteDownloadParams): Promise<