GitHub

发表于 2023-06-24 更新于 2024-12-01 分类于 develop 本文字数： 7.6k 阅读时长 ≈ 7 分钟

GitHub

profile README

github 个人主页介绍可通过配置一个仓库名和用户名相同中的 README.md 来生成.

开发者可以通过工具 markscribe 自动生成用户 README.md, 用于显示于个人 github 主页

参考示例如下:

GitHub CI/CD

links:

variables and secrets

links:

常用变量

github context
- github.ref_name
  - if: ${{ github.ref_name == 'main' }}
- github.ref
  - if: startsWith(github.ref, 'refs/tags')
- github.event.repository.default_branch
  - if: ${{ github.ref_name == github.event.repository.default_branch }}

continue on error

在上一个 step 失败后继续执行下一步 step

jobs:
  my-job:
    runs-on: ubuntu-latest
    steps:
      - name: Step 1
        run: echo "This step will fail" && exit 1
      - name: Step 2
        continue-on-error: true # 或者使用 if: ${{ failure() }}
        run: echo "This step will run even if Step 1 fails"
      - name: Step 3
        run: echo "This step will not run if Step 1 or Step 2 fails"

在此示例中，步骤 1 将失败，因为它使用 exit 1 退出时带有错误代码。但是，步骤 2 具有 continue-on-error: true 属性，这意味着即使步骤 1 失败，它也将继续运行。如果步骤 1 或步骤 2 失败，步骤 3 将不会运行。

links:

https://stacktuts.com/how-to-run-a-github-actions-step-even-if-the-previous-step-fails-while-still-failing-the-job

call workflow

workflow_call 是 GitHub Actions 中的一个关键字，它允许在一个工作流中调用另一个工作流。这个功能在 GitHub Actions 中是相对较新的，它可以帮助更好地组织和复用 CI/CD 代码。

links:

https://github.com/devcontainers-contrib/features/blob/main/.github/workflows/release.yaml

act

act 用于本地测试 GitHub Action 管道，避免频繁推送到远程测试 CI 流程。

手动安装需要各个平台安装工具

# bash
curl -s https://raw.githubusercontent.com/nektos/act/master/install.sh | bash
# choco
choco install act-cli
# winget
winget install nektos.act
# gh release
gh extension install https://github.com/nektos/gh-act

通过 devcontainer feature 支持 act

[!TIP]
建议在 vscode devcontainer 配置 dind 进行测试。

1
2
3

"features": {
    "ghcr.io/devcontainers-contrib/features/act:1": {}
}

常用命令

# 列出 actions jobs/workflows
act --list/-l
# Stage  Job ID  Job name  Workflow name  Workflow file     Events
# 0      build   build     build          devcontainer.yml  pull_request,push

# 运行 actions job, -v --verbose
act -j <job ID> -v

# 传递 secrets, 匹配actions yaml中引用方式 `${{ secrets.DOCKER_REGISTRY_PASS }}`
act -s DOCKER_REGISTRY_ID=1234 -s DOCKER_REGISTRY_PASS=1234

# 打开 debug log
act -v

# 运行 workflow
act -W <workflow id/file>

actions

links:

action token

Actions 的 TOKEN 认证有 GITHUB_TOKEN, PERSONAL_TOKEN

GITHUB_TOKEN: 是 GitHub 提供的一种特殊类型的令牌，用于对 GitHub API 进行身份验证和授权。它主要用于执行与 GitHub 相关的操作，例如创建和管理存储库、发布问题和拉取请求等。
- 默认没有 workflow 权限
PERSONAL_TOKEN: 是用户自己生成的令牌，用于对 GitHub 进行身份验证和授权。它可以用于执行与 GitHub API 相关的操作，但权限范围可能会受到限制，取决于用户在生成令牌时所选择的权限。
- 可手动设置 workflow 权限，参考

总结来说，GITHUB_TOKEN 是由 GitHub 提供的特殊令牌，用于对 GitHub API 进行身份验证和授权，而 PERSONAL_TOKEN 是用户自己生成的令牌，也用于对 GitHub 进行身份验证和授权，但权限可能会受到限制。

dependabot

Dependabot 是一个自动化的依赖更新工具，它可以帮助保持项目中的依赖库和组件的最新版本。它可以扫描项目的依赖关系，并自动检测是否有新版本可用。如果有新版本可用，Dependabot 会自动创建一个拉取请求（Pull Request）来更新依赖库。

为项目配置 Dependabot 的步骤如下：

在项目的代码仓库中，创建一个名为.github 的文件夹（如果还没有的话）。
在.github 文件夹中创建一个名为 dependabot.yml 的文件。
在 dependabot.yml 文件中，使用 YAML 格式来配置 Dependabot 的行为。

下面是一个示例的 dependabot.yml 文件的内容：

version: 2
updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "daily" # weekly, monthly

在这个示例中，配置了一个更新规则，用于更新 GitHub Actions 的依赖库。具体的配置可以根据项目和需求进行调整。

将 dependabot.yml 文件提交到代码仓库中。

一旦配置完成并提交到代码仓库，Dependabot 将会根据配置自动检查并更新项目中的依赖库。可以根据需要调整配置，例如更改更新的频率、指定特定的依赖库等。

请注意，Dependabot 支持多种不同的依赖管理工具和生态系统，可以根据项目使用的工具进行相应的配置。详细的配置选项和示例可以在 Dependabot 的官方文档中找到。

action dev

links:

https://github.com/sfeir-open-source/sfeir-school-github-action-dev

common actions

这里收集了常用到的 action

links:

https://github.com/autowarefoundation/autoware-github-actions

dockerhub/ghcr

docker/login-action@v2 example

steps:
    # ...

  - name: Login to DockerHub
    uses: docker/login-action@v2
    with:
      username: ${{ secrets.DOCKER_REGISTRY_ID }}
      password: ${{ secrets.DOCKER_REGISTRY_PASS }}

  - name: Login to GitHub Container Registry
    uses: docker/login-action@v2
    with:
      registry: ghcr.io
      username: ${{ github.repository_owner }}
      password: ${{ secrets.GITHUB_TOKEN }}

Sync images from dockerhub to ghcr example

steps:
    # ...

  - # ghcr logins for pushing image after testing
    name: Login to GitHub Container Registry
    uses: docker/login-action@v2
    with:
      registry: ghcr.io
      username: ${{ github.repository_owner }}
      password: ${{ secrets.GITHUB_TOKEN }}
  - name: Login to DockerHub
    uses: docker/login-action@v2
    with:
      username: ${{ secrets.DOCKER_REGISTRY_ID }}
      password: ${{ secrets.DOCKER_REGISTRY_PASS }}
  - # copy 3rd party zookeeper image from dockerhub to ghcr
    name: Push Image (zookeeper) to target registries
    uses: akhilerm/tag-push-action@v2.0.0
    with:
      src: wurstmeister/zookeeper:latest
      dst: |
        ghcr.io/${{ github.repository_owner }}/3rdparty/zookeeper:latest
  - # copy 3rd party kafka image from dockerhub to ghcr
    name: Push Image (kafka) to target registries
    uses: akhilerm/tag-push-action@v2.0.0
    with:
      src: wurstmeister/kafka:latest
      dst: |
        ghcr.io/${{ github.repository_owner }}/3rdparty/kafka:latest