我们经常发布文档更新,此页面的翻译可能仍在进行中。有关最新信息,请访问英文文档。如果此页面上的翻译有问题,请告诉我们

关于持续集成

您可以直接在 GitHub 仓库中通过 GitHub 操作 创建自定义持续集成。

GitHub 操作 目前在有限公测阶段,可能会有变动。强烈建议在公测期间不要将此功能用于高价值工作流程和内容。

更多信息请参阅“关于 GitHub 操作”。

本文内容:

关于持续集成

持续集成 (CI) 是一种需要频繁提交代码到共享仓库的软件实践。 频繁提交代码能较早检测到错误,减少在查找错误来源时开发者需要调试的代码量。 频繁的代码更新也更便于从软件开发团队的不同成员合并更改。 这对开发者非常有益,他们可以将更多时间用于编写代码,而减少在调试错误或解决合并冲突上所花的时间。

提交代码到仓库时,可以持续创建并测试代码,以确保提交未引入错误。 您的测试可以包括代码语法检查(检查样式格式)、安全性检查、代码覆盖率、功能测试及其他自定义检查。

创建和测试代码需要服务器。 您可以在推送代码到仓库之前在本地创建并测试更新,也可以使用 CI 服务器检查仓库中的新代码提交。

关于使用 GitHub 操作 的持续集成

使用 GitHub 操作 的 CI 提供默认工作流程,可在您的仓库中创建代码,然后在 GitHub 托管的服务器上运行测试。 工作流程在虚拟环境中的云托管服务器上运行,可以访问您的仓库的克隆版本。 更多信息请参阅“GitHub 操作 的虚拟环境”。

您可以配置 CI 工作流程在 GitHub 事件发生时运行(例如,当新代码推送到您的仓库时)、按设定的时间表运行,或者在使用仓库分发 web 挂钩的外部事件发生时运行。

GitHub 运行 CI 测试并在拉取请求中提供每次测试的结果,因此您可以查看分支中的更改是否引入错误。 如果工作流程中的所有 CI 测试通过,您推送的更改可供团队成员审查或合并 如果测试失败,则是其中某项更改导致了失败。

如果在仓库中设置了 CI,GitHub 会分析仓库中的代码,并根据仓库中的语言和框架推荐 CI 工作流程。 例如,如果您使用 Node.js,GitHub 将提议使用模板文件来安装 Node.js 包和运行测试。 您可以使用 GitHub 提议的 CI 工作流程模板,自定义提议的模板,或者创建自定义工作流程文件来运行 CI 测试。

提议的持续集成模板截屏

除了帮助设置项目的 CI 工作流程之外,您还可以使用 GitHub 操作 创建跨整个软件开发生命周期的工作流程。 例如,您可以使用操作来部署、封装或发行项目。 更多信息请参阅“[关于 GitHub 操作

](/articles/about-github-actions)”。

支持的语言

GitHub 提供各种不同语言和框架的 CI 工作流程模板。

浏览 actions/starter-workflows 仓库中 GitHub 提供的 CI 工作流程模板完整列表。

通过 GitHub 操作 持续集成的核心概念

这些是使用通过 GitHub 操作 的持续集成时的一些公共术语,具有特定的含义。

工作流

A configurable automated process that you can set up in your repository to build, test, package, release, or deploy any project on

GitHub . Workflows are made up of one or more jobs and can be scheduled or activated by an event.

Workflow run

An instance of your workflow that runs when the pre-configured event occurs. You can see the jobs, actions, logs, and statuses for each workflow run.

Workflow file

The YAML file that defines your workflow configuration with at least one job. This file lives in the root of your GitHub repository in the .github/workflows directory.

Job

A defined task made up of steps. Each job is run in a fresh instance of the virtual environment. You can define the dependency rules for how jobs run in a workflow file. Jobs can run at the same time in parallel or be dependent on the status of a previous job and run sequentially. For example, a workflow can have two sequential jobs that build and test code, where the test job is dependent on the status of the build job. If the build job fails, the test job will not run.

步骤

A step is a set of tasks performed by a job. Each step in a job executes in the same virtual environment, allowing the actions in that job to share information using the filesystem. Steps can run commands or actions.

作用

Individual tasks that you combine as steps to create a job. Actions are the smallest portable building block of a workflow. You can create your own actions, use actions shared from the GitHub community, and customize public actions. To use an action in a workflow, you must include it as a step.

Continuous integration (CI)

The software development practice of frequently committing small code changes to a shared repository. With GitHub 操作, you can create custom CI workflows that automate building and testing your code. From your repository, you can view the status of your code changes and detailed logs for each action in your workflow. CI saves developers time by providing immediate feedback on code changes to detect and resolve bugs faster.

Continuous deployment (CD)

Continuous deployment builds on continuous integration. When new code is committed and passes your CI tests, the code is automatically deployed to production. With GitHub 操作, you can create custom CD workflows to automatically deploy your code to any cloud, self-hosted service, or platform from your repository. CD saves developers time by automating the deployment process and deploys tested, stable code changes more quickly to your customers.

虚拟环境

GitHub hosts Linux, macOS, and Windows virtual environments to run your workflows.

Runner

A GitHub service in each virtual environment that waits for available jobs. When a runner picks up a job, it runs the job's actions and reports the progress, logs, and final results back to GitHub. Runners run one job at a time.

Event

A specific activity that triggers a workflow run. For example, activity can originate from GitHub when someone pushes a commit to a repository or when an issue or pull request is created. You can also configure a workflow to run when an external event occurs using the repository dispatch webhook.

Artifact

构件是创建并测试代码时所创建的文件。 例如,构件可能包含二进制或包文件、测试结果、屏幕截图或日志文件。 Artifacts are associated with the workflow run where they were created and can be used by another job or deployed.

工作流程运行通知

If you enable email or web notifications for GitHub 操作, you'll receive a notification when any workflow runs that you've triggered have completed. The notification will include the workflow run's status (including successful, failed, neutral, and canceled runs). You can also choose to receive a notification only when a workflow run has failed.

You can also see the status of workflow runs on a repository's Actions tab. 更多信息请参阅“管理工作流程运行”。

Status badges for workflow runs

Status badges show whether a workflow is currently failing or passing. A common place to add a status badge is in the README.md file of your repository, but you can add it to any web page you'd like. Badges display the status of your default branch (usually master).

For more information, see "Configuring a workflow."

延伸阅读

问问别人

找不到要找的内容?

联系我们