태그 보관물: github

GitHub release에 바이너리 첨부 자동화

GitHub에서 release를 생성하면 source code의 snapshot이 zip과 tar.gz로 저장된다. 여기에 추가해서 컴파일된 결과가 자동으로 추가하도록 한다면, 간단히 source code와 연계된 바이너리도 함께 배포할 수 있을 것이다.

이 글에서는 안드로이드 프로젝트를 가정해서 release를 생성할 때 안드로이드 APK를 빌드하고 source code와 함께 배포하는 간단한 workflow를 설명한다.

전체 코드

Event trigger

on:
  release:
    types: [published]

Release에서만 동작하므로 event trigger는 release – published이다. 이 event는 web상에서 새로운 release package를 publish 할때 trigger 된다.

환경변수

env:
  TAG: ${{ github.ref_name }}
  ASSET_FILE_PATH: "./prebuilt-${{ github.ref_name }}.zip"

Release package를 생성할 때 넣는 version의 이름은 github.ref_name으로 참조 된다. 첨부되는 파일의 이름은 prebuilt-<version_tag>.zip으로 설정한다. 참고로 GitHub에서는 release에 추가되는 소스코드외의 파일들을 “Asset”이라 부른다.

빌드 수행 및 Asset 생성

    # Checkout source code and build Android APKs.
    - name: Checkout
      uses: actions/checkout@v3
    - name: Setup JDK 17
      uses: actions/setup-java@v3
      with:
        java-version: '17'
        distribution: 'temurin'
        cache: gradle
    - name: Build Android APK and zip
      run: |
        sh ./gradlew assemble
        zip ${{ env.ASSET_FILE_PATH }} \
          ./app/build/outputs/apk/debug/app-debug.apk \
          ./app/build/outputs/apk/release/app-release*.apk

Android build를 위한 JAVA를 설정하고 Gradle의 assemble target을 설정하여 APK file에 대한 빌드를 수행한다. Assemble은 debug와 release용 두개의 apk를 성성하므로 이들을 하나의 zip파일로 만들어서 prebuilt-<version_tag>.zip에 추가한다.

Release에 Asset 추가

Release에 asset을 추가해주는 GitHub action은 보이질 않는다. 그래서 GitHub script를 이용해서 release에 asset을 추가하는 동작을 다음과 같이 정의했다. 이는 두 개의 동작으로 이루어지는데 하나는 주어진 tag로 release 정보를 찾아오는 것이고, 다른 하나는 가져온 release 정보에 파일을 업로드하는 것이다.

동작 1. Tag로 release 가져오기

GitHub script project의 README.md에 따르면 GitHub script상에서 github객체는 사전인증된(pre-authenticated) Octokit client라고 한다. 따라서 새롭게 instance를 만들지 않고 바로 Octokit의 API를 사용할 수 있다. getReleaseByTag()에 tag를 넘겨주면 통해 release에 대한 객체가 반환된다. 그 중에 release를 구분하기 위한 ID만 사용한다.

    // Get a release for given tag.
    const release = await github.rest.repos.getReleaseByTag({
       owner: context.repo.owner,
       repo: context.repo.repo,
       tag: process.env.TAG
    });
    const release_id = release.data.id;
    console.log("Release id for the tag " + process.env.TAG + ": " + release_id);

동작 2. Release에 파일 업로드 하기

앞의 과정에서 만든 업로드할 zip파일과 release를 구분할 ID 정보를 uploadReleaseAsset()에 넘겨 주면 해당 파일이 asset으로 등록된다.

    // Upload release assets.
    const fs = require("fs");
    const filename = process.env.ASSET_FILE_PATH.replace(/^.*[\\/]/, "");
    var uploaded = await github.rest.repos.uploadReleaseAsset({
       owner: context.repo.owner,
       repo: context.repo.repo,
       release_id: release_id,
       name: filename,
       data: await fs.readFileSync(process.env.ASSET_FILE_PATH),
    });
    console.log(
       process.env.ASSET_FILE_PATH
       + " has been uploaded as " + filename
       + " to the release " + process.env.TAG);

주의: upload 동작은 release를 수정하는 것이므로 workflow가 repository에 대한 write permission이 있어야 하므로 settings 항목에서 에서 write permission이 허가되어 있는지 확인한다. 이 부분이 안되어 있다면 403 error가 날 것이다.

Release workflow 실행

GitHub repo의 Code 탭에서 Tags -> Releases -> Tag -> Draft a new release를 선택한 후 Choose a tag를 눌러서 나오는 입력창에 새로 생성할 version tag를 입력해 Create new tag를 선택한 다음 Publish release 버튼을 누른다.

이 때 만들어지는 release에는 소스코드만 들어 있지만, 정상적으로 동작했다면 Actions tab에 release workflow가 등록되어 수행되는 것이 보일 것이다. Workflow가 정상 종료된 후 해당 release로 다시 가보면 asset이 등록되어 있는 것을 볼 수 있다.

Firewall 바깥의 git을 clone하기

Firewall등이 막고 있어서 외부의 git repository를 HTTPS로는 clone할 수 있지만 SSH로는 막히는 경우가 있다. 특히나 GitHub의 two-factor authentication을 설정한 경우라면 매번 token값을 입력하는 것 때문에 commit을 push하는게 매우 귀찮아진다.

이 문제는 ssh config file에 Proxy command를 설정해서 해결할 수 있는데
${HOME}/.ssh/config에 다음과 같이 추가해 주고, credential caching을 설정해 준다. (-S option에는 SOCKS port를 설정해야 함)

Host GitHub.com
  HostName github.com
  User git
  Port 22
  PorxyCommand connect-proxy -S {proxy-server}:{socks-port} %h %p

Travis CI 설정과 docker image 사용

GitHub project에 CI를 붙이고 싶은데 Jenkins server가 회사 firewall 안에 들어 있어서 GitHub에서 직접 webhook을 붙일 수 없는 문제가 있다. Jenkins의 GitHub plugin으로 tunneling을 설정하는 방법 등 있기는 하지만 다른 CI 옵션들을 살펴 보던중 Open source project에 대해서는 무료라는 Travis CI가 있다는 것을 알게 되었다. Travis CI는 기본으로 Ubuntu를 지원하고 그 외의 경우는 docker를 사용해서 환경을 설정할 수도 있다. 이 포스팅은 Travis CI에서 ClearLinux docker를 사용한 설정에 대한 기록이다.

삽질1: Travis CI의 Ubuntu이용

빌드와 Google test를 이용한 unit test만 할 것이니까 OS를 크게 타지 않을테니 기본으로 제공되는 Ubuntu 환경에 필요한 도구들만 설치 하면 가장 빠르지 않을까?

일견 타당해 보이기는 하지만 문제는 의존성이다. Pre-compile된 Google test를 download 받는다 해도, 2019년 1월 현재 아직 Travis CI에서 제공하는 Ubuntu의 가장 최신 버전은 Xenial이다. CMake version이 안맞아서 최신버전으로 설치하고 Intel LibVA, Intel MediaSDK등의 의존 package들을 컴파일한 후 빌드를 하고 unittest를 하도록 하는데 14분이 넘게 걸렸다. 다음은 사용한 .travis.yml file이다.

language: cpp 

compiler:  - gcc 

dist: xenial 

env:   
  global:    
- EA_INSTALL_PREFIX=${TRAVIS_BUILD_DIR}/local    
- PATH=${EA_INSTALL_PREFIX}/bin:$PATH before_install:  
- mkdir -p ${TRAVIS_BUILD_DIR}/local  
- sudo apt-get install curl wget autoconf libtool libdrm-dev \
libboost-all-dev libgstreamer1.0-0 libasound-dev \
libgles2-mesa-dev gstreamer1.0-plugins-base \
gstreamer1.0-plugins-good gstreamer1.0-plugins-bad \
gstreamer1.0-plugins-ugly gstreamer1.0-libav gstreamer1.0-doc \
gstreamer1.0-tools gstreamer1.0-x gstreamer1.0-alsa \
gstreamer1.0-pulseaudio
- cd ${TRAVIS_BUILD_DIR}&& \
wget https://github.com/Kitware/CMake/releases/download/v3.13.2\
/cmake-3.13.2.tar.gz \
&& tar xvf cmake-3.13.2.tar.gz&&cd cmake-3.13.2&&./configure --\
prefix=${EA_INSTALL_PREFIX}&&make&&make install  
- cd ${TRAVIS_BUILD_DIR}&& \
wget https://github.com/intel/libva/archive/2.3.0.tar.gz&&\
tar xvf 2.3.0.tar.gz \
&&cd libva-2.3.0&&./autogen.sh&&./configure --\
prefix=${EA_INSTALL_PREFIX}&&make&&make install  
- cd ${TRAVIS_BUILD_DIR}&& \
wget https://github.com/Intel-Media-SDK/MediaSDK/archive/\
intel-mediasdk-18.3.1.tar.gz \
&& tar xvf intel-mediasdk-18.3.1.tar.gz&&\
cd MediaSDK-intel-mediasdk-18.3.1/&& \
cmake -DCMAKE_INSTALL_PREFIX=/usr -DENABLE_OPENCL=OFF -DBUILD_SAMPLES=OFF .&&make&&\
make install 

script:  
- cd ${TRAVIS_BUILD_DIR} && \
cmake . && make && make install && test/ea_test

삽질2: Clear Linux docker image 사용 

시간만 오래 안 걸렸어도 기본 Ubuntu OS로 어떻게든 해보는 건데, 14분이면 시간이 너무 오래 걸린다. 이왕 시간이 오래 걸리는 거라면 타겟인 Clear Linux docker image를 사용해보자.

Clear Linux docker image를 생성하기 위한 dockerfile을 다음과 같이 작성해준 다음

FROM clearlinux

RUN clrtrust generate

RUN swupd bundle-add software-defined-cockpit-dev

.travis.yml file을 다음과 같이 선언해 준다.

language: cpp
services:
 - docker
before_install:
 - docker build -t clearlinux_ea .
 - docker run -d -v ${TRAVIS_BUILD_DIR}:/src clearlinux_ea /bin/sh -c "cd /src;cmake .;make;make install"

script:	 	 
 - docker run -d -v ${TRAVIS_BUILD_DIR}:/src clearlinux_ea /bin/sh -c "cd /src;test/ea_test"

총 소요된 시간은 17분 41초 그 중에 docker 설정하는데 걸린 시간만 16분이 넘는다. 나머지 시간에 unit test. 대부분의 시간이 docker를 빌드 하고 설정하는데 사용 되고 있었다. 

삽질3: 만들어 둔 Docker image 다운로드

빌드하는데 시간이 오래 걸린다면 이미 만들어 둔 docker image를 저장소에 넣어두고 pull해서 사용하면 좀 빠르지 않을까? Docker 빌드 vs Docker 다운로드.

이미 빌드 한 docker image를 공개 저장소인 docker hub에 넣어두고 Travis CI에서 pull하도록 변경하면 시간은 8분정도로 줄어든다.

language: cpp

services:
 - docker
	
before_install:
 - docker pull litcoder/clearlinux_ea
 - docker run -v ${TRAVIS_BUILD_DIR}:/src litcoder/clearlinux_ea /bin/sh -c "cd /src;cmake .;make;make install;"
	
script:
 - docker run -v ${TRAVIS_BUILD_DIR}:/src litcoder/clearlinux_ea /bin/sh -c "cd /src;test/ea_test"

흠.. 일단은 이걸로.

 결론

Travis CI에서 제공되는 연산 성능은 매우 떨어져서 컴파일이나 도커 빌드를 효율적으로 수행하지 못한다. 반면, 이미 만들어진 이미지의 다운로드는 상대적으로 빠르게 수행 할 수 있다. Travis CI에서 Docker를 이용한 테스트 환경을 구성하고자 한다면 미리 만들어 둔 이미지를 Docker Hub에 올려두고 CI script에서 pull 해서 사용하는 방법이 가장 고려해 볼 만한 선택이다.