https://minu0807.tistory.com/154
여기서 만들었던 토이 프로젝트를 다른 곳에서 무료로 배포한 상태에서 방치를 하고 있었다.
최근 확인할 게 있어서 접속을 해보니 꺼져있길래 다시 배포하려고 하니 안 되는 상황이 발생했다.
처음 저 프로젝트를 마무리하고 깃허브에서 제공하는 pages에 배포를 해보려다가 봐도 이해가 잘 안 돼서 안 하고 있다가 오늘 적용시켰다.
1. 배포종류
먼저 레파지토리의 프로젝트를 pages 배포하는 방법에 여러 가지 방법이 있는 것 같았다.
그중 내가 해보려고 했던 방법은 2가지 였다.
1. gh-pages 브랜치를 이용한 자동화:
별도의 스크립트 없이 gh-pages라는 이름의 브랜치를 사용하면 자동으로 배포된다.
빌드된 파일들을 gh-pages 브랜치에 올리고, GitHub의 설정에서 'Pages' 섹션으로 가서 'Deploy from a branch' 옵션을 선택한 후 gh-pages 브랜치를 지정하면 된다.
2. 워크플로우 설정 스크립트를 이용한 GitHub Actions 자동화:
프로젝트의 루트 디렉터리에 .github/workflows라는 디렉터리를 생성하고, 여기에 워크플로우를 정의하는 YAML 파일을 배치한다.
이 파일에는 빌드 및 배포 프로세스가 자세히 정의되어 있다.
GitHub Actions는 이 스크립트에 따라 프로젝트를 자동으로 빌드하고 실행한다.
이 방법은 더 많은 커스터마이징과 복잡한 워크플로우를 처리할 수 있는 유연성이 제공된다.
이중에 난 2번의 방법을 선택했다.
처음엔 1번의 방법으로 진행했는데, env 파일을 레파지토리에 올리지 않아서 별도로 설정해줘야 하는 부분도 있고, gh-pages 브런치를 이용한 방법을 사용할 때 이 브런치에는 빌드 결과물인 dist 디렉터리 안에 있는 파일들만 올려야 해서 너무 번거롭다는 생각이 들었다.
2번의 방법의 경우 yaml 파일에 빌드-배포 프로세스를 정의하기 때문에 더 직관적이고 유연성이 있어서 선택했다.
2. GitHub Pages 설정
배포하고자 하는 깃허브 레파지토리를 가서 settings 탭으로 간다.
먼저 해당 레파지토리가 private이면 public으로 변경해줘야 한다.
pages 메뉴로 이동해서 Build and Deployment > Source의 값을 Github Actions를 선택한다.
그리고 프로젝트에 .env를 이용하는 게 있다면 Environments 메뉴로 이동해서 secrets를 추가해줘야 한다.
없다면 이건 패스해도 됨.
여기까지 작업하면 우선 설정이 끝난다.
3. 배포 준비
프로젝트 루트 디렉터리에 .github/workflows 디렉터리를 생성하고 그 안에 static.yml을 생성한다.
(깃허브에서 제공하는 정적페이지라 static이라고 이름을 정했는데 deploy나 다르게 지정해도 된다.)
그리고 안에 아래와 같이 작성
# GitHub Pages에 정적 콘텐츠를 배포하기 위한 간단한 워크플로우
name: Deploy static content to Pages
on:
# 기본 브랜치에 대한 푸시 이벤트 발생 시 실행
push:
branches: ['main']
# Actions 탭에서 수동으로 워크플로우를 실행할 수 있도록 구성
workflow_dispatch:
# GITHUB_TOKEN의 권한을 설정하여 GitHub Pages에 배포할 수 있도록 함
permissions:
contents: read
pages: write
id-token: write
# 동시에 하나의 배포만 허용하도록 구성
concurrency:
group: 'pages'
cancel-in-progress: true
jobs:
# 단순히 배포만 수행하기에 하나의 잡으로만 구성
deploy:
environment:
name: github-pages
url: ${{ steps.deployment.outputs.page_url }}
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Set up Node
uses: actions/setup-node@v3
with:
node-version: 16
#cache: 'npm'
- name: Install dependencies
run: npm install
- name: Build
run: npm run build
env:
VITE_PUBG_API_URL: ${{ secrets.VITE_PUBG_API_URL}}
VITE_PUBG_API_KEY: ${{ secrets.VITE_PUBG_API_KEY}}
VITE_FB_apiKey: ${{ secrets.VITE_FB_apiKey}}
VITE_FB_authDomain: ${{ secrets.VITE_FB_authDomain}}
VITE_FB_databaseURL: ${{ secrets.VITE_FB_databaseURL}}
VITE_FB_projectId: ${{ secrets.VITE_FB_projectId}}
VITE_FB_storageBucket: ${{ secrets.VITE_FB_storageBucket}}
VITE_FB_messagingSenderId: ${{ secrets.VITE_FB_messagingSenderId}}
VITE_FB_appId: ${{ secrets.VITE_FB_appId}}
VITE_FB_measurementId: ${{ secrets.VITE_FB_measurementId}}
- name: Upload artifact
uses: actions/upload-pages-artifact@v1
with:
# dist 디렉터리 업로드
path: './dist'
- name: Setup Pages
uses: actions/configure-pages@v3
- name: Deploy to GitHub Pages
id: deployment
uses: actions/deploy-pages@v2
사용하는 env 값이 없다면 env 쪽은 빼도 된다.
secrets 부분은 위에 깃허브 페이지에서 추가한 secrets키들이 저기로 들어간다.
https://ko.vitejs.dev/guide/static-deploy.html#github-pages
여기에 있는 내용을 그대로 가져와서 조금만 수정했다.
빌드 배포 할 브랜치가 main이 아니고 다른 브랜치로 사용하려면 변경해도 된다.
내가 저 프로젝트를 만들 당시 node버전을 16으로 사용했기 때문에 16으로 설정했다.
그리고 빌드 디렉터리가 dist가 아니면 그에 맞게 변경해주면 된다.
현재 깃허브 pages를 활성화하면
https://<USERNAME>.github.io/<REPO>/ 이런 형식의 주소가 생성되기 때문에 vite.config.ts의 base 속성을 추가해 주거나 이미 있으면 수정해줘야 한다.
이렇게 해주면 된다.
그리고 router 쪽도 수정해줘야 한다.
vite.config.ts만 수정해 놓고 라우터 쪽을 수정 안 해서 계속 접속 안되던 문제랑.... 특정 부분이 계속 안 보였는데
이걸 생각 못해서 이상한 곳에서 계속 원인을 찾다가 몇 시간을 허비했었다.
이 외에 소스상에 경로와 관련된 부분이 있다면 수정을 해줘야할 수도 있다.
4. 배포
yml파일에 main 브랜치에 푸시가 발생하면 빌드하고 배포하게 설정되어 있기 때문에 작업 후 푸시를 하면 자동으로 실행된다.
실행되는 모습은 깃허브 페이지에서 Actions 탭을 가면 볼 수 있다.
빌드 실패했을 경우
잘못된 정보가 있다면 지적 부탁드립니다.
'VueJS > Vite' 카테고리의 다른 글
[VueJS] Vite에 NuxtJS의 layouts, pages 규칙 적용해보기 (0) | 2023.02.06 |
---|---|
[VueJS] Firebase 구글 로그인(Vite, Vue3, TS) (0) | 2023.01.24 |
[VueJS] Vite+Vue3 JWT기능 구현하기 (0) | 2022.04.25 |
[VueJS] vite에 axios, interceptors 적용하기 (0) | 2022.03.03 |
[VueJS] Vite에서 env 사용하기 (0) | 2022.02.19 |