Github Actions의 환경변수는 실행중인 셀, 프로세스가 참조하고 있는 key-value 쌍의 데이터이다.이 환경변수는 runner의 OS 환경변수, Actions가 제공하는 컨텍스트 기반의 값, 워크플로에서 선언하는 env, 런타임에 파일로 주입하는 env 등이 존재한다. 각각 범위의 순서대로 Workflow → Job → Step → 셀 런타입에 동적으로 주입 하는 순서로 우선순위는 반대로 좁은 우선순위가 우선되고 이는 Step → Job → Workflow → runner OS → 셀 런타입 주입값 순서대로 가진다. 여기서 우리가 볼 건 Workflow, Job, Step, 런타임 주입 이다. 환경 변수는 내부적으로 env라는 명령어를 통해서 할당해서 사용되는데 보다보면 그러면 왜 outpu..

OutputGithub Actions에서는 Job간에 직접적인 변수의 공유가 되지 않는다.그렇기에 다른 Job에서 값을 갖고 오기위해서 Output이라는 것을 사용하는데 Output은 앞 단계(Step, Job 등)가 계산한 값을 뒤 단계가 쓰도록 전달하는 공식적인 통로이다.CI파이프 라인은 보통 단계가 나뉘어져 있고 앞에서 만든 결과(버전, 경로, 계산값, 지정한 옵션 등)를 다음 단계가 알아야하는 경우가 많고 그걸 해결하기 위해서 output이라는 기술을 사용한다. 여기서 output은 세가지의 방향성을 볼 수 있는데 이는 각각 step → 동일 job의 stepjob → 다른 job재사용 단위의 output (Composite Action / Reusable Workflow) 과 같이 사용 된다. ..

Artifact아티팩트는 워크 플로우의 Job의 Step에서 만든 결과물을 파일로 저장하고 같은 워크플로우의 다른 Job에 넘겨 사용하거나 실행이 끝난 뒤 사람이 다운로드 해서 확인하거나 다른 워크플로우의 잡에서 받아서 후속 작업을 하도록 하는 저장물이다.이는 Job끼리는 병렬로 실행되며 각자 다른 러너에 의해서 실행되기에 파일이 연속적으로 유지되지 않기 때문에 사용되는 기술이다.업로드 : upload-artifact아티팩트는 업로드라는 것을 통해서 원하는파일을 저장하여 하나의 아티팩트로 만들어준다.이때 이 업로드는 Job의 Step에서 이뤄지며 uses에 actions/upload-artifact@버전 을 사용해서 아티팩트를 만든다.uses: actions/upload-artifact@v4 이 업로드 ..

Spring Boot로 만든 개인 프로젝트에서의 CI/CD의 구축이번에 해보고자 하는 CI/CD의 흐름은 먼저 로컬에서 코드를 작성한 후에 그 내용을 Github에 Push하게 된다.그러면 Github Actions가 이벤트를 확인해서 workflow를 실행해서 러너의 내부에서 AWS의 EC2로 원격 접속을 한 후에 Git을 통해서 Pull을 해서 해당 소스를 AWS의 EC2로 통합한다. 이러면 전체 프로그램 자체를 다 교체하는 방식이 아니라 지금 Push한 내용에 대해서만 교체하기 때문에 속도와 비용 면에서 이점을 가지게 된다. 그러나 빌드작업 자체는 EC2자체에서 직접 진행하는데 빌드가 컴퓨터의 성능을 많이 먹는 작업이기 때문에 운영하고 있는 서버의 성능에 영향을 줄 수 있다.또한 Github 계정의..

Cache캐시는 워크플로우 실행마다 다시 받아오거나 빌드해야하는 무거운 파일들을 저장해뒀다가 다음 실행 때에 재사용할 수 있도록 하는 저장소 같은 개념으로 프로젝트 내부의 node_modules나 pip, Gradle/Maven같은 라이브러리나 빌드 산출물과 같이 재사용 가능한 중간 결과들을 캐시해서 재사용하도록 한다. 이렇게 cache해서 사용하면 의존성의 설치, 컴파일 속도를 크게 줄여주고 러너의 사용 시간을 줄여 비용을 절감할 수 있으며 외부 레지스트리 지연 시에도 캐시로 빠르게 실행이 가능하다. 더보기여기서 나는 조금 혼동이 생겼다. 기존에는 로컬에서 서버에 필요한 라이브러리를 모두 설치하고 소스코드와 라이브러리를 포함한 형태로 빌드하여 그 산출물을 통해서 서버를 실행했었는데 github acti..

Timeout특정 시간 이상 실행되면 job / step을 자동으로 중단시키는 안전장치로 아무 설정이 없으면 360분(6시간)에 워크플로우(정확하게는 job이)가 강제로 종료된다. 사용하는 이유는 아래와 같다 무한대기/행(hang) 방지 :외부 서비스 지연, 네트워크 이슈, 데드락 등으로 run이 무한으로 돌아가는 상황을 차단한다비용 / 러너 자원 보호 : 불필요한 시간소요와 러너 점유로 큐가 막히는 문제를 예방한다피드백 가속 : 빨리 실패하게하여 문제를 조기에 감지 및 리턴한다.이 타임 아웃은 Job 단위로 사용하는데 필요시에는 Step 단위로 상세하게 적용하기도 한다. Job 단위 Timeout먼저 job 단위로 timeout을 거는 방법에 대해서 살펴보자.파일을 하나 생성해주고name을 생성해주고 ..