이 튜토리얼은 GitLab CI에 초점을 맞추고 있지만, 다른 CI/CD 플랫폼에 적응하기 위해 약간의 조정을 통해 사용할 수 있습니다.
인터뷰
앱을 Capgo에 추가했는지 확인하세요. 이 튜토리얼은 업로드 단계만 다룹니다.
커밋 규칙
커밋 규칙을 따르기 시작하세요. conventional commits`이것은 도구가 버전 번호를 업그레이드하는 방법을 이해하는 데 도움이 됩니다. 5분 만에 배울 수 있습니다.`
GitLab CI for tag
그런 다음 첫 번째 GitLab을 자동으로 빌드하고 태그를 생성하기 위해 만들 필요가 있습니다.
Create a file at this path: .github/workflows/bump_version.yml
__CAPGO_KEEP_0__
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이 작업을 완료하면 main branch의 모든 커밋에 대해 태그를 릴리스하고 main branch의 모든 커밋에 대한 변경 로그 항목을 추가합니다. CHANGELOG.md.
이 파일이 없다고 걱정하지 마세요. 이 파일은 자동으로 생성됩니다.
이 작업을 완료하려면 __CAPGO_KEEP_1__ GitLab CI/CD 변수에 추가해야 합니다. PERSONAL_ACCESS_TOKEN.
CI가 변경 로그를 커밋할 수 있도록 하기 위해 이것이 필요합니다.
토큰을 생성할 때 never 만료 기간을 __CAPGO_KEEP_2__으로 선택하고 범위(__CAPGO_KEEP_3__)으로 선택하세요. 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 이것은 처음 한 번만 필요합니다. 그 후 도구는 자동으로 최신 버전을 유지합니다.
__CAPGO_KEEP_0__에 첫 번째 태그가 나타날 수 있습니다.
GitHub 빌드 액션
GitHub actions for build
내용을 추가해야 합니다. .github/workflows/build.yml
이것은 의존성을 설치하고 빌드한 후 __CAPGO_KEEP_0__로 전송합니다.
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_KEEP_0__에서 변경할 수 있습니다. build_code To make this work, you need to get your __CAPGO_KEEP_0__ key for __CAPGO_KEEP_1__, add it in the
To make this work, you need to get your API key for Capgo, add it in the secret of your GitHub repository You can now commit this both files and see your first tag appear in __CAPGO_KEEP_0__! CAPGO_TOKEN.
You can now commit this both files and see your first tag appear in GitHub!
You should add your test in the build step to ensure your __CAPGO_KEEP_0__ is working.
Go To your code dashboard and check your build who just appeared, you now have your CI/CD system.
Go To your Capgo dashboard and check your build who just appeared, you now have your CI/CD system.
Keep going from Automatic build and release with Gitlab public.
If you are using
Automatic build and release with Gitlab 자동으로 빌드 및 릴리즈를 Gitlab과 함께 계속하세요. CI/CD 자동화 계획을 수립하기 위해 연결하세요. Capgo CI/CD Capgo CI/CD에서 제품 워크플로우를 위해 Capgo 네이티브 빌드 Capgo 네이티브 빌드에서 제품 워크플로우를 위해 Capgo 통합 Capgo 통합에서 제품 워크플로우를 위해 CI/CD 통합 CI/CD 통합 구현 세부 사항에 대해 GitHub 액션 통합 GitHub 액션 통합 구현 세부 사항에 대해
