# 아주 간단한 깃헙 액션

# 자동 배포하기

깃허브 액션 워크플로우를 통해 자동으로 도커 이미지를 빌드하고 컨테이너를 실행하는 형태의 자동 배포도 가능하다.

```yml
name: Deploy to Remote Server

on:
  push:
    branches:
      - main

permissions:
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Setup SSH Key
        run: |
          echo "${{ secrets.SSH_KEY }}" | base64 -d > key.pem
          chmod 600 key.pem

      - name: Pull and Restart on Server
        run: |
          ssh -i key.pem -p ${{ secrets.SSH_PORT }} -o StrictHostKeyChecking=no ${{ secrets.SSH_USER }}@${{ secrets.SSH_HOST }} << 'EOF'
            cd ${{ secrets.REMOTE_DIR }}
            echo "[INFO] Pulling latest changes..."
            git pull origin main
            echo "[INFO] Stopping old container..."
            docker stop discord-bot-toko || true
            docker rm discord-bot-toko || true
            echo "[INFO] Rebuilding image..."
            docker build -t discord-bot-toko .
            echo "[INFO] Starting container..."
            docker run -d --name discord-bot-toko --env-file .env --rm discord-bot-toko
          EOF
```

위 코드의 경우 실제로는 배포상 문제가 있었으나, 위와 같은 식으로 push가 있는 경우 도커 이미지를 빌드하고 도커 컨테이너를 재실행하는 디자인으로 작성되었다.

# 테스트 만들기

러스트에서도 테스트들을 만들 수 있다.

```yml
name: Audit

on:
  schedule:
    - cron: "0 0 * * 0" # Every Sunday at midnight
  workflow_dispatch: # Manual trigger

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # Toolchain installation
      - name: Install Rust
        uses: actions-rs/toolchain@v1
        with:
          toolchain: stable

      # cargo-audit
      - name: Install cargo-audit
        run: cargo install --locked cargo-audit

      # check known vulnerabilities
      - name: Run cargo-audit
        working-directory: vulncat
        run: cargo audit
```

위와 같은 식으로 알려진 취약점에 대한 테스트도 작성할 수 있다. 위의 경우 일요일 자정 또는 수동 트리거에 의해 작동시킬 수 있다.

# 배포

`release`를 이용해 자동으로 태그를 달고 배포하는 용도로도 사용 가능하다.

```yml
name: Release

on:
  push:
    tags:
      - "v*.*.*"

jobs:
  release:
    runs-on: ubuntu-latest

    defaults:
      run:
        working-directory: vulncat/model

    steps:
      - uses: actions/checkout@v4
      - name: Install Rust
        uses: actions-rs/toolchain@v1
        with:
          toolchain: stable

      - name: Run full build & tests
        run: |
          cargo build --release
          cargo test

      - name: Create GitHub Release
        uses: actions/create-release@v1
        id: create
        with:
          tag_name: ${{ github.ref_name }}
          release_name: Release ${{ github.ref_name }}
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

      - name: Upload trained model
        uses: actions/upload-release-asset@v1
        with:
          upload_url: ${{ steps.create.outputs.upload_url }}
          asset_path: models/autoencoder.bin
          asset_name: autoencoder.bin
          asset_content_type: application/octet-stream
```

# 린터 적용

파이썬 프로젝트의 경우 github action 웹에서 간단하게 `pylint`를 적용할 수 있다. 다만 기본 설정을 그대로 적용할 경우 파이린트 점수가 10점 이상이여야 테스트 성공이 나오나, 만약 머지를 막아놓은 경우 파이린트 10점이 꽤 강한 제한으로 느껴질 수 있다.

이러한 경우에

```yml
name: Pylint

on: [push]

permissions:
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python-version: ["3.13"]
    steps:
    - uses: actions/checkout@v4
    - name: Set up Python ${{ matrix.python-version }}
      uses: actions/setup-python@v3
      with:
        python-version: ${{ matrix.python-version }}
    - name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        pip install pylint
    - name: Analysing the code with pylint
      run: |
        pylint $(git ls-files '*.py') --fail-under=7.5
```

아래 이렇게 점수를 설정해줘서 테스트의 강도를 조절할 수 있는데

`pylint $(git ls-files '*.py') --fail-under=7.5`인 경우 7.5 이상에서 테스트가 통과하게 된다.