Github Actions(CI/CD 구축) - .gitignore에 추가된 파일의 주입

프로젝트를 하다보면 Github에 올리지 않으면서 관리되어야 할만한 정보들이 담긴 파일들이 존재한다.

그런 파일들은 .gitignore를 통해서 Github에 올라가지 않도록 설정이 가능한데 이 파일이 아예 프로그램에서 사용되지 않는게 아니기 때문에 빌드할때 사용되기 위해서 Github Actions에서 직접 주입하는 형태로 구현한다.

 

먼저 application.properties를 보자.

위와 같이 application.properties같은 경우는 DB에 대한 정보들을 담고 있고 이걸 통해서 우리의 프로젝트의 DB에 모두 접근이 가능하다.

이런 보안적인 문제들이 존재하기 때문에 이를 우리는 workflow에서 주입해서 사용하도록 할 것이다.

 

우선 .gitignore에 application.properties를 추가해주고

우리가 commit을 할때 application.properties를 포함하지 않게 되면 commit을 할 수 없기 때문에 임의의 파일을 하나 생성해주고 

이제 git add . 을 해주고 난 후에 status를 해보자.

보면 아직 해당 파일을 git이 추적하고 있는 상태임을 알 수 있다.

 

이건 깃이 해당 파일을 이미 추적했었기 때문에 캐시로 해당 파일을 추적해야하는 상태라고 알고 있기 때문이다

git rm -r --cached .

- rm : Git 인덱스에서 제거한다
- -r : 재귀적으로(디렉터리를 제거하기 위해서) 처리한다
- --cached : 로컬 파일은 지우지 않고 인덱스에서만 제거한다
- . : 대상은 현재 디렉터리 전체를 대상으로 한다

이는 git 이 추적하는 대상을 .gitignore를 기준으로 다시 추적시킬 수 있도록 리프레쉬 한다고 생각하면 된다.

이때 만약 add를 했다면 add 이전의 상태로 변경된다.

 

git add .을 해주면

이렇게 deleted되었다고 나온다.

이제 commit & push를 해주면

github에서는 사라진것을 확인할 수 있다.

이제 이걸 workflow를 통해서 주입하도록 만들어보자.

 

Workflow를 통해 파일 주입하기

workflow에 파일을 주입하기 위해서는 환경변수를 사용하게 된다

우선적으로 secrets에 해당 값을 먼저 넣어줘야 하기에 github에서 secrets값을 하나 생성해주자.

상단 메뉴인 Settings > 좌측 메뉴바의 Secrets and variables > Actions > New repository secret을 눌러주고

내용은 우리 기존에 application.properties에 있던 내용을 넣어주자.

그리고 Add secret을 눌러서 

secret을 추가해주자.

 

이제 workflow파일로 돌아가서 step부분에 env로 환경변수를 생성해주는데 여기서 secret을 사용해서 값을 주입해준다.

그리고 이렇게 받은 값을 with의 envs에 아래와 같이 추가해준다.

이건 appleboy/ssh-action의 옵션으로 runner에 있는 환경 변수들 중에서 원격 SSH 세션으로 전달할 변수의 이름을 지정하는 것으로 원격 EC2에서 해당 변수를 사용하기 위해서는 위와 같이 envs에 추가해줘야 한다.

만약 envs에 추가하지 않으면 그냥 문자 그대로 혹은 빈값이 전달된다(이는 원격 쉘 입장에선 그냥 미정의 변수이기 때문).

이렇게 추가되었다면 echo 명령어를 통해서 application.properties로 출력해주면 

나중에 빌드 할때 이 파일이 포함되어서 빌드가 진행되게 된다.

 

이제 commit & push 해주면

정상적으로 workflow가 실행되었다 

 

이제 EC2로 접속해서 확인해보자.

추가 되어 있는걸 볼 수 있다.

내용을 출력해서 확인해보면

우리가 주입한대로 들어간걸 확인할 수 있다.

 

##그런데 만약에 runner 안에서 checkout을 받고 난 다음에 빌드해서 jar파일로 뽑았어도 압축 풀면 그대로 있다고 함

그래서 사실상 이런거는 jar안에 포함시키지 않는게 정석이라고 한다.

 

Github Actions의 테스트

Springboot 프로젝트에서 보면 test라는 항목이 존재한다

해당 부분은 src/main/java 내부에 우리가 만든 프로덕션 코드를 검증하기 위한 부분으로 보통 프로덕션 코드와 패키지 구조를 미러링 하는 것이 관례로 구성되어 있다

src/main/java와 src/test/java와 구조가 동일함

간단하게 com.example.demo.service.UserService라는 파일에 대한 테스트는 src/test/java/com/example/demo/service/UserServiceTest.java에 둔다.

 

한번 해당 소스파일을 열어보면

이렇게 되어 있고 최초 테스트가 가능한 하나의 메서드가 존재한다.

 

contextLoads() 메서드는 그냥 앱이 제대로 켜지는지를 확인하는 확인용 메서드로 스프링을 진짜 그냥 한번 켜서 정상적으로 에러 없이 켜지는지를 확인한다.

내부에 아무런 검증 코드가 없어도 정상적으로 부팅이 가능하다면 정상적으로 실행 및 종료된다.

실행한는 방법은 프로젝트의 루트에서 아래와 같이 실행하면 된다.

./gradlew test

이렇게 테스트가 정상적으로 됨을 확인할 수 있다.

 

이제 여기서 contextLoad()의 내부에 RuntimeException을 뜨게끔 설정하고

다시 테스트를 돌려보면

이렇게 빌드에 실패했다고 나오고 

프로젝트의 /build/reports/tests/test/index.html를 눌러 켜보면

이렇게 에러의 내용까지 확인할 수 있다.

 

이상태에서 push 해보면 

이렇게 테스트가 포함되어 있어서 정상적이지 않을 경우 배포를 하지 않게 된다.