注: GitHub 托管的运行器目前在 GitHub Enterprise Server 上不受支持。 您可以在 GitHub 公共路线图 上查看有关未来支持计划的更多信息。
Introduction
GitHub Actions offers features that let you control deployments. You can:
- Trigger workflows with a variety of events.
- Configure environments to set rules before a job can proceed and to limit access to secrets.
- Use concurrency to control the number of deployments running at a time.
For more information about continuous deployment, see "About continuous deployment."
Prerequisites
You should be familiar with the syntax for GitHub Actions. For more information, see "Learn GitHub Actions."
Triggering your deployment
You can use a variety of events to trigger your deployment workflow. Some of the most common are: pull_request
, push
, and workflow_dispatch
.
For example, a workflow with the following triggers runs whenever:
- There is a push to the
main
branch. - A pull request targeting the
main
branch is opened, synchronized, or reopened. - Someone manually triggers it.
on:
push:
branches:
- main
pull_request:
branches:
- main
workflow_dispatch:
For more information, see "Events that trigger workflows."
Using environments
环境用于描述一般的部署目� �,如生产
、暂存
或开发
。 当 GitHub Actions 工作流程部署到某个环境时,该环境将显示在存储库的主页上。 您可以使用环境来要求批准才能继续作业,限制哪些分支可以触发工作流程,或限制对机密的访问。 有关创建环境的更多信息,请参阅“使用环境进行部署”。
Using concurrency
Concurrency ensures that only a single job or workflow using the same concurrency group will run at a time. You can use concurrency so that an environment has a maximum of one deployment in progress and one deployment pending at a time.
Note: concurrency
and environment
are not connected. The concurrency value can be any string; it does not need to be an environment name. Additionally, if another workflow uses the same environment but does not specify concurrency, that workflow will not be subject to any concurrency rules.
For example, when the following workflow runs, it will be paused with the status pending
if any job or workflow that uses the production
concurrency group is in progress. It will also cancel any job or workflow that uses the production
concurrency group and has the status pending
. This means that there will be a maximum of one running and one pending job or workflow in that uses the production
concurrency group.
name: Deployment
concurrency: production
on:
push:
branches:
- main
jobs:
deployment:
runs-on: ubuntu-latest
environment: production
steps:
- name: deploy
# ...deployment-specific steps
You can also specify concurrency at the job level. This will allow other jobs in the workflow to proceed even if the concurrent job is pending
.
name: Deployment
on:
push:
branches:
- main
jobs:
deployment:
runs-on: ubuntu-latest
environment: production
concurrency: production
steps:
- name: deploy
# ...deployment-specific steps
You can also use cancel-in-progress
to cancel any currently running job or workflow in the same concurrency group.
name: Deployment
concurrency:
group: production
cancel-in-progress: true
on:
push:
branches:
- main
jobs:
deployment:
runs-on: ubuntu-latest
environment: production
steps:
- name: deploy
# ...deployment-specific steps
For guidance on writing deployment-specific steps, see "Finding deployment examples."
Viewing deployment history
When a GitHub Actions workflow deploys to an environment, the environment is displayed on the main page of the repository. For more information about viewing deployments to environments, see "Viewing deployment history."
Monitoring workflow runs
Every workflow run generates a real-time graph that illustrates the run progress. You can use this graph to monitor and debug deployments. For more information see, "Using the visualization graph."
You can also view the logs of each workflow run and the history of workflow runs. For more information, see "Viewing workflow run history."
Tracking deployments through apps
You can also build an app that uses deployment and deployment status webhooks to track deployments. 当引用环境的工作流程作业运行时,它会创建一个部署对象,并将 environment
属性设置为环境的名称。 随着工作流程的进行,它还会创建部署状态对象,其中 environment
属性设置为环境的名称,environment_url
属性设置为环境的 URL(如果在工作流程中指定), state
属性设置为作业的状态。 For more information, see "Apps" and "Webhook events and payloads."
Choosing a runner
You can run your deployment workflow on GitHub-hosted runners or on self-hosted runners. Traffic from GitHub-hosted runners can come from a wide range of network addresses. If you are deploying to an internal environment and your company restricts external traffic into private networks, GitHub Actions workflows running on GitHub-hosted runners may not be able to communicate with your internal services or resources. To overcome this, you can host your own runners. For more information, see "About self-hosted runners" and "About GitHub-hosted runners."
Displaying a status badge
You can use a status badge to display the status of your deployment workflow. 状态徽� 显示工作流程目前失败还是通过。 添� 状态徽� 的常见位置是仓库的 README.md
文件,但也可将其添� 到您喜欢的任何网页。 默认情况下,徽� 显示默认分支的状态。 您也可以在 URL 中使用 branch
和 event
查询参数显示特定分支或事件运行的工作流程状态。
For more information, see "Adding a workflow status badge."
Finding deployment examples
This article demonstrated features of GitHub Actions that you can add to your deployment workflows.
GitHub Enterprise Server 为� 种流行的服务(如 Azure Web App)提供部署入门工作流程。 若要了解如何开始使用入门工作流程,请参阅“使用入门工作流程”或浏览部署入门工作流程的完整列表。 还可以查看有关特定部署工作流程的更详细指南,例如“部署到 Azure App 服务”。
许多服务提供商还会在 GitHub Marketplace 上提供用于部署其服务的操作。 有关完整列表,请参阅 GitHub Marketplace。