管理操作和工作流
在本部分中,你将探索 GitHub Enterprise Cloud 和 GitHub Enterprise Server 中提供的不同工具和策略,以便共享 GitHub 操作和工作流,并管理它们在企业中的使用。
内容是围绕着所提供的工具的级别来构造的:企业级别或组织级别。
在企业层面
配置 GitHub Actions 使用策略
GitHub Actions 工作流通常包含操作,即在工作流程中执行的一组独立命令。 在创建工作流时,你可以创建自己的操作来使用或引用 GitHub 市场中提供的公共社区操作。 出于此原因,在企业中配置工作流和操作的使用策略,对于防止用户使用恶意的第三方操作至关重要。
Enterprise Cloud 中提供了几个选项来配置策略,Enterprise Server 中也是如此(如果在企业设置中启用了 GitHub Connect)。
若要为企业配置 GitHub Actions 使用策略,请导航到企业帐户,然后导航到边栏中的“策略”>“操作”。 系统应显示以下选项。
顶部标记为“为所有组织启用”的下拉列表可用于确定企业中的哪些组织可以使用 GitHub Actions(全部、部分或无),而下面的三个选项可用于定义这些组织内 GitHub Actions 的限制级别。
如果想要仅启用在企业中使用的特定操作,请选择“允许企业,并选择非企业、操作和可重用工作流”,然后选择与用例对应的选项。
为 Enterprise Server 手动同步公共操作
大多数由 GitHub 创作的官方操作会自动与 Enterprise Server 捆绑,并在某个时间点从 GitHub 市场中捕获。 它们包括 actions/checkout
、actions/upload-artifact
、actions/download-artifact
、actions/labeler
和各种 actions/setup-
操作等。 若要获取企业实例中包含的所有官方操作,请浏览到实例上的操作组织:https://HOSTNAME/actions.
如配置 GitHub Actions 使用策略部分中所述,可以将 Enterprise Server 配置为自动访问 GitHub 市场中提供的公共操作,并为其配置使用策略。 但是,如果你希望更严格地控制应在企业中使用的公共操作,可以使用 actions-sync
工具手动下载操作并将其同步到企业实例中。
组织级别
记录企业标准
创建 GitHub Actions 工作流通常涉及到编写多个文件和创建多个存储库,以指定工作流本身。 创建还包括要在工作流中使用的操作、容器和/或运行器。 根据 Enterprise Cloud 和 Enterprise Server 实例中的用户数,如果还没有建立创建 GitHub Actions 工作流的企业标准,工作很快就会乱作一团。
作为最佳做法,我们建议将以下内容记录到 GitHub wiki 中,或将其作为 Markdown 文件存储在组织内部均可访问的存储库中:
- 用于存储的存储库
- 文件/文件夹命名约定
- 共享组件的位置
- 日常维护计划
- 贡献准则
创建工作流模板
工作流模板可以很好地确保在企业中重复使用和维护自动化。 在 Enterprise Cloud 和 Enterprise Server 中,具有对组织 .github 存储库的写入访问权限的用户都可以创建工作流模板,该模板可用于具有相同写入访问权限的其他组织成员。 然后,可以使用工作流模板在组织的公共和专用存储库中创建新的工作流。
创建工作流模板的过程分为两个步骤:
创建 yml 工作流文件。
创建一个 json 元数据文件,描述在创建工作流时应向用户显示模板的方式。
注意
元数据文件必须具有与工作流文件相同的名称。 必须向它追加 .properties.json,而不是 .yml 扩展名。 例如,名为 octo-organization-ci.properties.json 的文件包含名为octo-organization-ci.yml的工作流文件的元数据。
这两个文件都必须放在公共 .github 存储库和名为 workflow-templates 的目录中。 如果组织中还不存在这些文件,可能需要创建它们。
下面是基本工作流文件的示例:
name: Octo Organization CI
on:
push:
branches: [ $default-branch ]
pull_request:
branches: [ $default-branch ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Run a one-line script
run: echo Hello from Octo Organization
请注意,上述文件使用 $default 分支占位符。 使用模板创建工作流时,此占位符会自动替换为存储库的默认分支的名称。
您可以为工作流文件创建以下元数据文件:
{
"name": "Octo Organization Workflow",
"description": "Octo Organization CI workflow template.",
"iconName": "example-icon",
"categories": [
"Go"
],
"filePatterns": [
"package.json$",
"^Dockerfile",
".*\\.md$"
]
}
元数据文件使用以下参数:
参数 | 描述 | 必需 |
---|---|---|
姓名 | 可用模板列表中显示的工作流模板的名称。 | 是 |
说明 | 可用模板列表中显示的工作流模板的说明。 | 是 |
图标名称 | 在模板列表中定义工作流条目的图标。 必须是同名的 SVG 图标,并且必须存储在工作流模板目录中。 例如,名为example-icon.svg的 SVG 文件被引用为示例图标。 | 否 |
categories | 定义工作流的语言类别。 当用户查看可用模板时,匹配相同语言的模板将更为突出。 | 否 |
filePatterns | 如果用户的存储库在其根目录中具有与定义的正则表达式匹配的文件,则启用模板。 | 否 |
创建工作流模板后,组织中的用户可以在“操作”>“新建工作流”>“_your_organization_name 创建的工作流”下找到该模板。
操作和工作流的可重用模板
GitHub Actions 允许 工作流自动化,有效管理工作流的关键部分是使用 可重用模板。 可重用模板有助于标准化和简化跨多个存储库的开发,减少冗余并提高可维护性。
GitHub Actions 中的可重用模板是指可在多个项目中引用和使用 预定义的作和工作流 。 它们确保与企业整体标准的一致性和合规性。
可重用模板的类型
模板类型 | 用途 | 示例 |
---|---|---|
可重用工作流 | 跨存储库标准化 CI/CD 管道。 | ci-pipeline.yml 、deploy-app.yml |
可重用操作 | 封装常见的自动化逻辑。 | setup-env-action 、security-scan-action |
工作流模板 | 定义可重用的作业结构。 | test-job.yml 、build-job.yml |
可重用工作流
可重用工作流是在单独的存储库中定义的工作流,可在多个项目中引用。 这样,组织就可以 集中 其 CI/CD 逻辑。
可重用工作流的结构
可重用工作流存储在 .github/workflows/
中,并使用 workflow_call
触发器。
示例:标准化 CI 工作流(ci-pipeline.yml)
name: CI Pipeline
on:
workflow_call:
inputs:
node-version:
required: true
type: string
secrets:
npm-token:
required: true
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Set up Node.js
uses: actions/setup-node@v3
with:
node-version: ${{ inputs.node-version }}
registry-url: 'https://npm.pkg.github.com/'
- name: Install Dependencies
run: npm install
- name: Run Tests
run: npm test
在另一个存储库中使用可重用工作流
定义后,可以通过关键字在任何存储库 uses:
中使用可重用工作流。
例: 调用可重用工作流
name: Reusable CI Pipeline
on: push
jobs:
test:
uses: org/reusable-workflows/.github/workflows/ci-pipeline.yml@v1
with:
node-version: '16'
secrets:
npm-token: ${{ secrets.NPM_TOKEN }}
使用可重用工作流的好处
- 确保所有存储库都遵循相同的 CI/CD 结构。
- 减少冗余和维护开销。
- 允许 集中更新 ,而无需修改每个存储库。
可重用的行动
GitHub Action 是一个模块化的可重用单元,用于执行特定的自动化任务。 组织通常会创建自定义动作来封装常用的逻辑。
可重用动作的结构
可重用操作是使用 action.yml
文件在操作存储库中定义的。
例: 自定义设置环境操作
name: "Setup Environment"
description: "Sets up Node.js and installs dependencies"
inputs:
node-version:
description: "Node.js version"
required: true
registry-url:
description: "NPM Registry URL"
required: false
default: "https://registry.npmjs.org/"
runs:
using: "node16"
main: "index.js"
在工作流中使用可重用操作
与其在每个工作流中重复设置步骤,我们选择使用自定义动作:
name: Build & Test
on: push
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Setup Environment
uses: org/actions/setup-env@v1
with:
node-version: '16'
好处:
- 减少跨存储库设置逻辑的重复。
- 简化工作流文件,使其更易于阅读。
- 集中化更新——一个地方的修复或改进会影响所有工作流程。
工作流模板
如前所述,工作流模板通过为常见任务提供预定义的结构来帮助标准化整个组织的自动化。 这些模板是更广泛的可重用工作流类别的关键部分。
在前面的“创建工作流模板”部分中,我们概述了如何从 yml
文件和相应的 .properties.json
元数据文件生成这些模板。
为了进一步连接概念:工作流模板是一种可重用工作流的形式。 当你在workflow-templates/
目录下的公共.github
存储库中创建和存储它们时,它们允许其他组织成员为他们的存储库创建一致的工作流,而无需从头开始定义这些工作流。
通过利用工作流模板,企业可以:
- 跨存储库强制实施最佳做法。
- 加快新项目的载入和设置。
- 在 CI/CD 进程中保持一致性。