티스토리 뷰

일반적으로 workflow는 여러 개의 job들이 있고

해당 job들이 모두 성공적이라면 성공이 뜨지만 3가지의 job이 있다고 했을때 2번째 job이 실패했다고하면 3번째 job은 실행되지 않는다. 

실패한 시점에서 끝나게 되는것.

하지만 if를 사용하여 위와 같은 상황을 조건을 주어 실패를 해도 step 및  job을 실행시킬수가 있다.

 

true / false 값 알아내기

 ......step....
 
      - name: Test code
        id: run-tests #모든 단꼐에 고유 id를 설정할수 있음, 다른단계나 작업에 사용하기 위한.
        run: npm run test
      - name: Upload test report
        #이 if문은 오로지 테스트가 실패한게 맞으며 테스트의 id인 run_test의 outcome이 failure일때 해당 step이 작동하도록 하는 것이다.
        if: failure() && ${{ steps.run_tests.outcome == 'failure' }} #테스트가 실패하면 작동하도록 설정. 
        uses: actions/upload-artifact@v3
        with:
          name: test-report
          path: test.json
          
 ......job....

 

if절로 조건을 주어서 해당 step이 true인지 false인지 알아내야한다.

steps.<step_id>.outcome == 'failure'

• Job의 모든 단계에서 이 컨텍스트에 액세스 할수 있다. 

• 해당 id에 접근하여 결과 정보를 얻어올수 있다.

• 결과값을 얻어올 step에 id: 를 통해 id를 지정해줄수 있다.

• outcome의 값은 success, failure, cancelled, skipped와 같은 값이 문자열로 오는데 이것과 비교해서 조건을 주면된다. 

context 관련 내용 - GitHub Actions / Contexts

Expressions 관련 내용 - GitHub Actions / Expressions

 

if절에서 사용가능한 함수 if: <function()>

failure()

 - 이전단계나 작업이 실패했을 경우 true반환

 - 이전 작업에서 오류가 발생했거나 필요한 작업이 완료되지 않았을 때 특정 작업을 실행하려는 경우에 유용

success()

 - 이전단계가 실패하지 않았을때 true반환

 - 특정 작업을 이전 작업이 성공적으로 완료되었을 때 실행하려는 경우에 사용

always()

 - 항상 true반환, 조건 없이 항상 실행

 - 특정 작업을 항상 실행하려는 경우에 사용

cancelled()

 - 워크플로가 취소되었다면 취소된 반환은 true

 - 워크플로가 강제로 중단되었거나 사용자에 의해 취소되었을 때 특정 작업을 실행하려는 경우에 유용

 

 

false값으로 Job 실행시키기 

  report:
    needs: [lint, deploy]
    if: failure()
    runs-on: ubuntu-latest
    steps:
      - name: Output information
        run: | 
          echo "Something went wrong"
          echo "${{ toJSON(github) }}"

위 코드를 보면 lint와 deploy작업이 끝나고 나서 실행을 한다.

하지만 그에 대한 조건으로는 lint와 deploy가 실패일때 밑의 github실행컨텍스트의 정보를 가져오도록 하였다.

이런식으로 조건을 달았을때 report라는 작업은 if조건을 통과하면 실행하게 되고

통과를 못하면 작업은 실행되지 않는다.

 

 

Cache 적용하기

    steps:
      - name: Get code
        uses: actions/checkout@v3 # GitHub 리포지토리의 코드를 체크아웃
      - name: Cache dependencies
        id: cache
        uses: actions/cache@v3 # 종속성을 캐싱
        with:
          path: ~/.npm # 종속성이 저장된 디렉토리의 경로를 지정
          key: deps-node-modules-${{ hashFiles('**/package-lock.json') }} # 캐시의 식별자를 지정, 종속성의 변경 여부를 확인하기 위해 hashFiles 함수를 사용하여 package-lock.json 파일의 해시를 계산하고 이를 키에 포함
      - name: Install dependencies
        run: npm ci

이 부분은 캐시에 저장은 하지만

무조건 적으로 종속성이 캐시에 저장되었는지 여부와 관계없이 npm ci를 진행한다.

 

개발자의 궁극적인 목표는 같은 기능을 하지만 더 빠르고 더 효율적으로 보다 더 깔끔하게 하는 구현하는 것이 목표이다.

 

그러기 위해서 약간의 수정과 조건을 달아주어야 한다.

1. 일단 모든 종속성이 들어있는 경로를 ~/.npm이 아닌 node_module파일로 하면 워크 플로를 더 가속화 시킬수 있다.

 

why?

~/.npm 디렉토리는 전역적으로 사용되는 npm 패키지를 저장하는 데 사용되는 반면,

node_modules 디렉토리는 각 프로젝트에 로컬로 설치되는 패키지를 저장하는 데 사용.

node_modules 디렉토리에 종속성을 저장하면 프로젝트의 종속성을 캐시할 때 시간을 절약할 수 있다.

왜냐하면 캐시를 불러오고 다시 설치하는 과정이 로컬 프로젝트 디렉토리에서 이루어지기 때문.

또한 package-lock.json 파일을 사용하여 정확한 종속성 버전을 유지할 수 있다.

 

종속성을 node_modules 디렉토리에 설치하는 것은 워크플로를 더 가속화시키고 효율적으로 만드는 데 도움이 된다.

 

 

2. if: steps.cache.outputs.cache-hit != 'true' 조건을 달아주어 가속화 시킬수 있다.

deps-node-modules-${{ hashFiles('**/package-lock.json') }}는 캐시 키를 생성하기 위한 문자열이다.

문자열은 package-lock.json 파일의 해시를 포함하여 캐시 키를 만드는 데 사용된다.

package-lock.json 파일의 내용이 변경되면 해당 파일의 해시 값도 변경되므로
파일의 변경 여부를 확인하고 필요한 경우에만 새로운 캐시를 생성할 수 있다.

이러한 과정이들어있는 컨텍스트가 id값인 cache에 들어가게 된다.

해당 아이디의 cache-hit를 확인하여 생성된 새로운 캐시가 사용되었는지 확인 할수도 있다.(true or false)

cache-hit는 캐시에서 성공적으로 항목을 검색하여 사용된 경우를 나타내는 용어이다.

이전에 캐시된 데이터가 현재 작업에서 필요한 경우에 사용되어 빠르고 효율적으로 작업이 수행되었다는 것을 의미한다.

이 부분은 github-action cache-hit에서 확인 해볼수 있다.

이부분을 조건으로 사용하여 조건을 판별할수 있다.만약 true가 아니라면 즉, 캐시가 사용되지 않았다면 npm ci로 종속성을 다시 설치하고true라면,즉 캐시가 사용되었다면 설치를 안하고 바로 넘어가서 다른 step을 진행할수 있는 것이다.즉, 종속성을 설치하는 시간을 건너뛸수 있는 것이다.

해당 파이프 라인에서 test는 캐시를 읽을수가 없다.

이 전에서 캐시를 한적이 없기 때문에

파일에서 보면 캐시를 찾을수가 없어서 새로운 키로 캐시를 저장했다.

또한 npm ci를 하여 종속성을 설치한것을 볼수 있다.

하지만 build는 test에서 cache에 key값을 찾았기 때문에 캐시를 복원하여 사용할수가 있다.

"Cache restored successfully"는 캐시가 성공적으로 복원되었음을 나타내는 메시지이며 캐시가 성공적으로 검색되고 로드되었음을 나타낸다.

그리고 install dependencies에서  npm ci로 종속성을 설치해야하는 부분의 조건이 벗어낫으므로 해당 step을 건너 뛴것을 볼수가 있다.

 

 

'Git & Github&배포' 카테고리의 다른 글

[CI / CD] Github Action - Matrix를 사용하여 버전 운영하기  (0) 2024.03.25
[CI/CD] Workflow Event  (0) 2024.03.21
[CI/CD]GitHub Action  (0) 2024.03.20
git 명령어  (0) 2024.03.19
AWS EC2 배포하기  (0) 2024.01.23
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
«   2024/11   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
글 보관함