GitHub 작업으로 CI/CD 패키지
앞서 말씀드린 바와 같이 저는 다음과 같은 것을 확보하고 싶습니다.
your-repo/.github/workflows/의 YAML 파일에 기록되며 일부 저장소 이벤트에서 수행됩니다.지속적인 통합
이런 자동화는 상대적으로 간단하다.저장소 주간에 제출할 때마다 다음 워크플로우를 실행하고 요청을 주간으로 가져올 때마다 다음 워크플로우를 실행하고 싶습니다.
golangci-lint 을 사용하여 linting 검사를 실행함으로써 문법을 테스트합니다. 이것은 가장 좋은 linter입니다. (실제로는 원 linter라고 생각합니다. 몇 개의 단독 linter를 사용했기 때문입니다.) 만약 당신이 모두가 알고 있는 반모드에 미끄러지면 손목을 두드릴 것입니다.모든 사람이 나무 줄기에 승낙하다
이 작업의 트리거는 워크플로우 파일 상단에 선언됩니다.
on:
push:
branches: [main]
pull_request:
branches: [main]
형식 검사를 통해 문법 테스트
먼저 GitHub's own
checkout action을 사용하여 GitHub Actions에서 저장소를 체크 아웃해야 합니다.그런 다음 GitHub's setup-go action을 사용하여 Go 버전을 설정해야 합니다.GitHub Actions에는 달리기 선수들이 사용할 수 있는 3가지 운영체제가 있는데 각 운영체제마다 Go versions이 다르지만 가장 안전한 방법은 어떤 Go 버전을 사용할지 명확하게 지정하는 것이다.마지막으로, 우리는 golangci-lint's provided GitHub Action을 사용하여 linting을 할 수 있다. 이것은 리포의 작업 흐름 실행 프로그램 복제에서
golangci-lint을 실행할 수 있으며, 리포의 어떤 Go 파일도 golangci-lint의 모든 linter 규칙에 부합되지 않으면 오류 코드를 출력할 수 있다.AST(즉, 어떤 문법 오류가 존재하면)을 해석할 수 없으면 golangci-lint이 실패하기 때문에 문법의 정확성을 검사하는 데도 사용할 수 있습니다. 이 자체가 충돌 문자열의 합병을 검사하는 좋은 에이전트입니다.이런 방식을 통해 어떤 검사도 곧 실패할 수 있다. 문법 오류가 발생하면 컴파일링과 go test 호출을 가속화할 필요가 없다.jobs:
lint:
name: Lint files
runs-on: 'ubuntu-latest'
steps:
- uses: actions/[email protected]
- uses: actions/setup-go@v2
with:
go-version: '1.16.4'
- name: golangci-lint
uses: golangci/[email protected]
with:
version: latest
테스트 기능
마찬가지로 이 작업에 대한 재구매 계약을 확인하고 Go 버전을 설정해야 합니다.
name: Run tests
runs-on: 'ubuntu-latest'
needs: lint
steps:
- uses: actions/[email protected]
- uses: actions/setup-go@v2
with:
go-version: '1.16.4'
- run: go test -v -cover
go test은 go.mod에 정의된 의존항을 자동으로 획득함)이나 가상 환경을 설정하는 데 어떠한 설정도 필요하지 않기 때문에 CI/CD의 템플릿 파일은 훨씬 적습니다.서로 다른 운영체제와 체계 구조의 구축 안정성을 시험하다
Go는 다양한 OS 및 아키텍처에 cross-compilation tooling을 제공합니다.기본적으로 다음 명령을 실행할 수 있습니다
$ GOOS=plan9 GOARCH=arm go build
GOOS에서 지정한 운영체제와 GOARCH에서 지정한arch에서 실행되는 바이너리 파일을 구축합니다.GOOS 및 GOARCH 옵션의 전체 목록을 보려면 go tool dist list을 실행하십시오.이 컬렉션의 구축 안정성을 확인하기 위해 GitHub 작업을 사용하여 GOO 및 GOARCH 옵션에 대한 매트릭스 구축을 설정할 수 있습니다.
build:
runs-on: 'ubuntu-latest'
needs: test
strategy:
matrix:
goosarch:
- 'aix/ppc64'
- 'android/amd64'
- 'android/arm64'
- 'darwin/amd64'
- 'darwin/arm64'
- 'dragonfly/amd64'
# ...
jobs.<job_id>.strategy.matrix directive에 정의되어 있다.나는 모든 GOOS와 GOARCH의 짝짓기에 하나의 변수만 추가했다(본문은 짧게 잘렸고 모두 39 pairs defined in my workflow file개의 변수가 있다).내부적으로 이러한 단계는 다음과 같습니다.
matrix.goosarch을 이 조합의 값으로 정의한다.goosarch 값을 참고하십시오.)기본적으로 이 매트릭스 옵션은 병렬로 실행되기 때문에 작업의 실행 시간은 가장 느린 매트릭스 옵션에 의해 결정됩니다.만약에 메모리 라이브러리가 개인이라면 각각의 단독 구축 매트릭스 옵션에 대해 약 hefty multipliers for macOS and Windows runners(2021년 5월부터 1개의 맥OS분은 10분의 조작 포인트, 1개의 Windows분은 2분의 조작 포인트)을 지불할 것입니다.일반적인 체크 아웃 및 Go 버전 설정을 수행한 다음
/ 문자에 기본 Bash 문자열 분할을 수행하여 단일 매트릭스 옵션에서 각각 GOOS 및 GOARCH 환경 변수를 설정할 수 있습니다. - name: Get OS and arch info
run: |
GOOSARCH=${{matrix.goosarch}}
GOOS=${GOOSARCH%/*}
GOARCH=${GOOSARCH#*/}
BINARY_NAME=${{github.repository}}-$GOOS-$GOARCH
echo "BINARY_NAME=$BINARY_NAME" >> $GITHUB_ENV
echo "GOOS=$GOOS" >> $GITHUB_ENV
echo "GOARCH=$GOARCH" >> $GITHUB_ENV
go build 하위 명령만 실행하면 바이너리 파일이 생성됩니다. - name: Build
run: |
go build -o "$BINARY_NAME" -v
자동 결합
GitHub은 또한 지점 보호 규칙을 설정하고pull 요청이 필요한 모든 심사와 상태 검사를 통과한 상황에서pull 요청을 자동으로 통합할 수 있습니다.재구매 설정 > 지점 > 지점 보호 규칙에서 나는
main에 대해 규칙을 정의했는데 지점이 build.yml으로 통합되기 전에 반드시 main 작업 흐름의 모든 작업을 통과해야 한다고 요구했다.게시 자동화
GitHub 출시 자동화는
GitHub 릴리스 작성
v에서 시작하는 레이블을 푸시할 때 트리거할 워크플로우를 설정했습니다.on:
push:
# Sequence of patterns matched against refs/tags
tags:
- 'v*' # Push events to matching v*, i.e. v1.0, v20.15.10
release 작업을 정의하여 Ubuntu(가장 저렴하고 빠른 GitHub Actions runner 환경)에서 실행합니다.name: Create Release
jobs:
autorelease:
name: Create Release
runs-on: 'ubuntu-latest'
build.yml과 같은 GOOS and GOARCH build matrix을 설치했습니다. GitHub 발행판을 만들 때, 이진 파일을 발행 자산으로 구축하고 업로드할 것입니다.우리의 앞의 두 단계는 우리의 전송과 PRs에서
main까지의 구축 작업 흐름과 거의 같다. 우리는 재구매를 서명하고 Go를 설정한다.그러나 서명 절차는 약간 다르다. 우리는 0 입력에 fetch-depth을 제공했기 때문에 모든 제출을 사용하여 깊이 있는 클론을 만들었지 최근에 제출한 얕은 클론만 사용한 것이 아니다. steps:
- name: Checkout code
uses: actions/checkout@v2
with:
fetch-depth: 0
- name: Get OS and arch info
run: |
GOOSARCH=${{matrix.goosarch}}
GOOS=${GOOSARCH%/*}
GOARCH=${GOOSARCH#*/}
BINARY_NAME=${{github.repository}}-$GOOS-$GOARCH
echo "BINARY_NAME=$BINARY_NAME" >> $GITHUB_ENV
echo "GOOS=$GOOS" >> $GITHUB_ENV
echo "GOARCH=$GOARCH" >> $GITHUB_ENV
- name: Build
run: |
go build -o "$BINARY_NAME" -v
.github 폴더에 게시 템플릿을 저장하고 gitlog 출력을 추가했습니다. - name: Release Notes
run: git log $(git describe HEAD~ --tags --abbrev=0)..HEAD --pretty='format:* %h %s%n * %an <%ae>' --no-merges >> ".github/RELEASE-TEMPLATE.md"
마지막으로, 우리는 3rd-party release creation Action을 사용하여 발표 초안을 만들었는데, 그 중에서 우리가 방금 만든 발행 설명과 부품을 포함한다.
- name: Release with Notes
uses: softprops/action-gh-release@v1
with:
body_path: ".github/RELEASE-TEMPLATE.md"
draft: true
files: ${{env.BINARY_NAME}}
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Pkg에 게시합니다.가자.덕부
발표 과정의 마지막 단계는 Pkg 알림입니다.가자.dev는 이 모듈의 새로운 버전을 사용할 수 있음을 표시합니다.완전한 workflow입니다.
이번에 릴리즈된 버전에서 워크플로우를 실행하도록 트리거했습니다(이전 워크플로우의 마지막 단계는 수동 릴리즈 초안):
on:
release:
types:
- published
curl을 go get으로 실행하십시오.jobs:
bump-index:
runs-on: ubuntu-latest
steps:
- name: Checkout repo
uses: actions/[email protected]
- name: Ping endpoint
run: curl "https://proxy.golang.org/github.com/jidicula/random-standup/@v/$(git describe HEAD --tags --abbrev=0).info"
이 모든 것을 함께 놓아라
따라서 이 프로젝트의 전반적인 작업은 다음과 같습니다.
main에 이 버전을 가리키는 표시를 만듭니다.너는 이 문장이 유용하다고 생각하니?음료수 한 잔 사주시거나 here 협찬해 주세요!
Reference
이 문제에 관하여(GitHub 작업으로 CI/CD 패키지), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://dev.to/jidicula/go-package-ci-cd-with-github-actions-350o텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
좋은 웹페이지 즐겨찾기
