跳过主内容
CI/CD

与Gitlab自动构建和发布

使用Gitlab免费创建自己的CI/CD管道,每次推送到main分支时都部署您的应用。

马丁·多纳迪厄

马丁·多纳迪厄

内容营销人员

与Gitlab自动构建和发布

本教程重点介绍GitLab CI,但您可以轻松适应任何其他CI/CD平台。

序言

确保您已在Capgo中添加了您的应用本教程仅关注上传阶段

提交约定

首先,您需要遵循提交规范 规范提交` 这将有助于工具了解如何升级版本号,学习时间仅5分钟。

规范提交

GitLab CI for tag

然后您需要创建第一个GitLab来自动构建并创建标签。

在这个路径创建一个文件: .github/workflows/bump_version.yml

内容如下:

name: Bump version

on:
  push:
    branches:
      - main

jobs:
  bump-version:
    if: "!startsWith(github.event.head_commit.message, 'chore(release):')"
    runs-on: ubuntu-latest
    name: "Bump version and create changelog with standard version"
    steps:
      - name: Check out
        uses: actions/checkout@v6
        with:
          fetch-depth: 0
          filter: blob:none
          token: '${{ secrets.PERSONAL_ACCESS_TOKEN }}'
      - name: Git config
        run: |
          git config --local user.name "github-actions[bot]"
          git config --local user.email "github-actions[bot]@users.noreply.github.com"
      - name: Create bump and changelog
        run: npx capacitor-standard-version
      - name: Push to origin
        run: |
          CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD)
          remote_repo="https://${GITHUB_ACTOR}:${{ secrets.PERSONAL_ACCESS_TOKEN }}@github.com/${GITHUB_REPOSITORY}.git"
          git pull $remote_repo $CURRENT_BRANCH
          git push $remote_repo HEAD:$CURRENT_BRANCH --follow-tags --tags

这将为每个主分支提交发布一个标签,并为每个主分支提交添加一个更改日志条目。 CHANGELOG.md.

如果您不了解这个文件,请不要担心,它将为您创建。

为了使其工作,请创建一个 个人访问令牌 并将其添加到您的 GitLab CI/CD 变量中 PERSONAL_ACCESS_TOKEN.

这有必要让 CI 提交 changelog。

当您创建令牌时,请选择过期时间为 never 并选择范围为 repo.

最后,要让工具了解您的版本保存在哪里,您必须创建文件 .cz.toml 在您的仓库根目录。

并添加以下内容:

[tool.commitizen]
name = "cz_conventional_commits"
tag_format = "$major.$minor.$patch$prerelease"
version = "0.11.5"
version_files = [
    "package.json:version",
    ".cz.toml"
]

将版本设置为此文件中的相同版本,您在 package.json 文件中。

这只在第一次必要,之后工具将自动更新。

您现在可以提交这两个文件并看到您的第一个标签出现在 GitHub 中!

GitHub 构建动作

创建一个文件到这个路径: .github/workflows/build.yml

带有这个内容:

name: Build source code and send to Capgo

on:
  push:
    tags:
      - '*'
      
jobs:
  deploy:
    runs-on: ubuntu-latest
    name: "Build code and release"
    steps:
      - name: Check out
        uses: actions/checkout@v6
      - name: Install dependencies
        id: install_code
        run: npm i
      - name: Build
        id: build_code
        run: npm run build
        env: # Remove both lines  if you don't need it
          FIREBASE_CONFIG: ${{ secrets.FIREBASE_CONFIG }} # Example of env var coming from a secret
      - name: Create Release
        id: create_release
        run: npx @capgo/cli@latest bundle upload -a ${{ secrets.CAPGO_TOKEN }} -c production

这将安装并构建您的依赖项,然后将其发送到 Capgo。

如果您的构建命令不同,您可以在 build_code 步骤中进行更改。

为了使其工作,您需要获取您的 API 密钥并将其添加到 Capgo 的 secret of your GitHub repository 您的 __CAPGO_KEEP_0__ 仓库的密钥。 CAPGO_TOKEN.

您现在可以提交这两个文件并看到您的第一个标签出现在 GitHub 中!

添加提交将为生产渠道生成一个新的构建。

您应该在构建步骤中添加您的测试,以确保您的 code 正在工作。

前往您的 Capgo 控制台并检查刚刚出现的构建,您现在有了您的 CI/CD 系统。

如果您希望您的所有用户在更新可用时都能获得更新,请转到您的频道并将其设置为 public.

Capacitor 应用的实时更新

当 web 层面的 bug 活跃时,通过 Capgo 发布修复,而不是等待几天的 app store 审批。用户在后台接收更新,而原生变化仍然在正常的审批路径中

立即开始

最新博客

Capgo 为您提供创建真正专业的移动应用所需的最佳见解。