适用于部署的 REST API 终结点

Enterprise Cloud

Enterprise Server 3.10

Enterprise Server 3.11

Enterprise Server 3.12

Enterprise Server 3.13

Enterprise Server 3.14

Enterprise Server 3.15

Free, Pro, & Team

REST API

所有 GitHub 文档都是开源的。 看到错误或不清楚的内容了吗？ 提交拉取请求。

帮助我们创建出色的文档！

域名

谁可以使用此功能？

操作

需要多个权限，或者可以使用不同的权限。 有关权限的更多信息，请参阅此终结点的文档。

输入搜索词以在 GitHub 文档中找到它。

适用于部署的 REST API 终结点 - GitHub Enterprise Server 3.13 Docs

使用 REST API 创建和删除部署密钥、部署和部署环境。

快速入门

REST API 简介

比较 GitHub 的 API

API 版本

重大更改

OpenAPI 描述

入门

速率限制

分页

Libraries

最佳做法

故障排除

时区

CORS 与 JSONP

议题事件类型

GitHub 事件类型

使用 REST API

身份验证

确保 API 凭据安全

适用于 GitHub Apps 安装令牌的终结点

适用于 GitHub Apps 用户令牌的终结点

细化 PAT 的终结点

GitHub 应用的权限

细化 PAT 的权限

使用 JavaScript 编写脚本

使用 Ruby 编写脚本

为用户发现资源

交付部署

将数据渲染为图形

处理注释

构建 CI 服务器

入门 - Git 数据库

开始 - 检查

加密机密

Guides

Artifacts

缓存

OIDC

权限

机密

自托管运行器组

自托管运行程序

变量

工作流程作业

工作流运行

工作流

事件

通知

标星

关注中

活动

组织

公告横幅

GitHub Apps

安装

OAuth 授权

Webhook

应用

计费

分支

受保护的分支

检查运行

检查套件

检查

代码扫描

行为准则

协作者

邀请

提交

提交注释

提交状态

警报

Dependabot

依赖项检查

依赖项提交

软件材料清单 (SBOM)

依赖关系图

部署密钥

部署分支策略

部署

环境

保护规则

部署状态

表情符号

管理统计

公告

审核日志

代码安全性和分析

全局 Webhook

LDAP

许可证

管理 GHES

管理控制台

组织预接收挂钩

预接收环境

预接收挂钩

存储库预接收挂钩

SCIM

用户

企业管理

Gists

Blob

参考

标记

Trees

Git 数据库

Gitignore

问题

受理人

里程碑

时间线

Markdown

元数据

统计信息

指标

迁移

OAuth 应用授权

自定义属性

自定义角色

成员

外部协作者

个人访问令牌

规则套件

规则

安全管理员

Boards

卡片

Projects (classic)

拉取请求

评价注释

审查请求

审阅

反应

发行版本

发布资产

自动链接

前叉

Git LFS

存储库

Search

机密扫描

全局安全公告

安全通知

Teams

讨论评论

讨论

外部组

电子邮件

关注者

GPG 密钥

Git SSH 密钥

社交帐户

SSH 签名密钥

A request for a specific ref(branch,sha,tag) to be deployed

Deployment

Simple filtering of deployments is available via query parameters:

The account owner of the repository. The name is not case sensitive.

owner

The name of the repository without the <code>.git</code> extension. The name is not case sensitive.

repo

The SHA recorded at creation time.

The name of the ref. This can be a branch, tag, or SHA.

The name of the task for the deployment (e.g., <code>deploy</code> or <code>deploy:migrations</code>).

task

The name of the environment that was deployed to (e.g., <code>staging</code> or <code>production</code>).

environment

The number of results per page (max 100). For more information, see "<a href="https://docs.github.com/enterprise-server@3.13/rest/using-the-rest-api/using-pagination-in-the-rest-api">Using pagination in the REST API</a>."

per_page

The page number of the results to fetch. For more information, see "<a href="https://docs.github.com/enterprise-server@3.13/rest/using-the-rest-api/using-pagination-in-the-rest-api">Using pagination in the REST API</a>."

page

List deployments

The ref to deploy. This can be a branch, tag, or SHA.

Specifies a task to execute (e.g., <code>deploy</code> or <code>deploy:migrations</code>).

Attempts to automatically merge the default branch into the requested ref, if it's behind the default branch.

auto_merge

The <a href="https://docs.github.com/enterprise-server@3.13/rest/commits/statuses">status</a> 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.

required_contexts

JSON payload with extra information about the deployment.

payload

Deployments offer a few configurable parameters with certain defaults.
The <code>ref</code> parameter can be any named branch, tag, or SHA. At GitHub Enterprise Server we often deploy branches and verify them
before we merge a pull request.
The <code>environment</code> parameter allows deployments to be issued to different runtime environments. Teams often have
multiple environments for verifying their applications, such as <code>production</code>, <code>staging</code>, and <code>qa</code>. This parameter
makes it easier to track which environments have requested deployments. The default environment is <code>production</code>.
The <code>auto_merge</code> 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.
By default, <a href="https://docs.github.com/enterprise-server@3.13/rest/commits/statuses">commit statuses</a> for every submitted context must be in a <code>success</code>
state. The <code>required_contexts</code> parameter allows you to specify a subset of contexts that must be <code>success</code>, 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.
The <code>payload</code> 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.
The <code>task</code> parameter is used by the deployment system to allow different execution paths. In the web world this might
be <code>deploy:migrations</code> to run schema changes on the system. In the compiled world this could be a flag to compile an
application with debugging enabled.
Merged branch response:
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:
<ul>
<li>Auto-merge option is enabled in the repository</li>
<li>Topic branch does not include the latest changes on the base branch, which is <code>master</code> in the response example</li>
<li>There are no merge conflicts</li>
</ul>
If there are no new commits in the base branch, a new request to create a deployment should give a successful
response.
Merge conflict response:
This error happens when the <code>auto_merge</code> option is enabled and when the default branch (in this case <code>master</code>), can't
be merged into the branch that's being deployed (in this case <code>topic-branch</code>), due to merge conflicts.
Failed commit status checks:
This error happens when the <code>required_contexts</code> parameter indicates that one or more contexts need to have a <code>success</code>
status for the commit to be deployed, but one or more of the required contexts do not have a state of <code>success</code>.
OAuth app tokens and personal access tokens (classic) need the <code>repo</code> or <code>repo_deployment</code> scope to use this endpoint.

Create a deployment