GitLabを使用した自動ビルドとリリース

このチュートリアルはGitLab CIに焦点を当てていますが、他のCI/CDプラットフォームに少し調整することで、他のプラットフォームでも使用できます。

序文

Capgoにアプリを追加することを確認してください。このチュートリアルはアップロードフェーズに焦点を当てています。

コミット規約

まずコミット規約を遵守する必要があります。 conventional commitsこの記法を使用すると、ツールがバージョン番号をアップグレードする方法を理解できるようになります。5分で学べます。

GitLab CI for tag

次に、GitLab CIを使用してタグを作成し、自動的にビルドする必要があります。

ファイルを作成するパス: .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.

このファイルが存在しない場合も、自動的に作成されます。

この機能を使用するには、 PERSONAL ACCESS TOKEN をGitLab CI/CD変数に追加してください。 PERSONAL_ACCESS_TOKEN.

CIが変更履歴をコミットできるようにするために必要です。

トークンを作成する際に、有効期限を never とスコープを repo.

に選択してください。 .cz.toml リポジトリのrootディレクトリにこのファイルを作成し、

に以下の内容を追加してください。

[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 ファイル。

これは最初の1回のみ必要です。その後、ツールは自動的に更新します。

この両方のファイルをコミットしてみてください。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に依存関係をインストールしてビルドし、Capgoに送信します。

ビルドのコマンドが異なる場合、ステップを変更してください。 build_code __CAPGO_KEEP_0__ キーを取得し、__CAPGO_KEEP_1__に追加してください。__CAPGO_KEEP_0__ リポジトリのシークレットに追加してください。

To make this work, you need to get your API key for Capgo, add it in the GitHub __CAPGO_KEEP_1__ CAPGO_TOKEN.

You can now commit these files and see your first tag appear in GitHub!

Add the commit will generate a new build for the production channel.

You should add your test in the build step to ensure your code is working.

Go to your Capgo dashboard and check your build who just appeared, you now have your CI/CD system.

If you want to let all of your users get the update whenever it’s available, go to your channel and set it to public.

Keep going from Gitlabの自動ビルドとリリース

If you are using Gitlabの自動ビルドとリリース to plan CI/CD automation, connect it with Capgo CI/CD for the product workflow in Capgo CI/CD, Capgo Native Builds 製品ワークフローにおけるCapgoネイティブビルドの Capgo統合 Capgo統合の製品ワークフローの CI/CD統合 CI/CD統合の実装詳細について、 GitHubアクション統合の GitHubアクション統合の実装詳細について