Cb-tumblebug: Workflow build-and-publish-container-image is time consuming

[seokho-son]

[이슈]
build-and-publish-container-image 워크플로우 수행시간이 너무 많이 걸려서(약 17분 ~ 20분 소요),
PR 리뷰에 어려움이 있음.

[개선 방안]
Build (테스트 및 이미징) 과 Publish 테스크를 별도의 워크플로우로 분리
(Publish 의 경우, PR이 승인 및 머지되고 나서 수행 가능해 보입니다. 또는 크론이벤트로 처리도 가능하겠네요.)

[seokho-son]

/cc @hermitkim1 @jihoon-seo
어떻게 생각하시나요 ~ ?

[jihoon-seo]

저도 좋다고 생각합니다.
PR 에 대해서는
amd64 이미지 빌드 테스트만 한다면
시간을 많이 줄일 수 있겠습니다.

[hermitkim1]

@seokho-son

좋은 의견 이십니다.

CB-Larva도 build-and-publish-container-image의 수행 시점에 대해 고민하고 있고요. 아래와 같은 계획을 가지고 있으니 참고 바랍니다.

현재 CB-Larva의 계획은
1) develop 브랜치에서 release-xxx 브랜치를 생성하는 시점에 build-and-publish-container-image를 수행하고,
2) release-xxx 브랜치를 master 또는 develop 브랜치로 PR하는 시점에 수행하는 것 입니다.

참고: BRANCHING-AND-RELEASING-STRATEGY

[hermitkim1]

@jihoon-seo 님의 의견을 반영한 수정안 입니다.

[수정 안]

• merged 이벤트 발생시: 기존 build-and-publish-container-image 워크플로우를 수정하여 활용
• PR(pull request) 이벤트 발생시: amd64 이미지만 빌드하는 신규 워크플로우 추가

[추가로 해결하고자 하는 이슈]

가능하면 이번 이슈를 해결하면서 아래 이슈를 함께 해결하고자 합니다.

• [이슈] forked repo에 upstream repo의 최신사항 반영 시 build-and-publish-container-image 워크플로우를 수행합니다.
  
  
  
  • 이벤트 상으로 보면 Local master를 Remote master에 Push 하는 경우 입니다.
  
  
  • build-and-publish-container-image 워크플로우에서 on-push 이벤트를 통해 merged를 판단하기 때문에 워크플로우가 수행됩니다.
  
  
  • 자칫 forked repo에서 검증되지 않은 Container Image를 Docker 또는 GHCR로 Publish 할 수 있어 개선하고자 합니다.
  
  

[jihoon-seo]

현재 build-and-publish-container-image.yaml 은 multi-arch 컨테이너 이미지 빌드를 위해 qemu 환경을 설정하는 부분도 들어가 있어서 시간이 좀 더 많이 걸리는 것 같습니다.
amd64 이미지만 빌드한다면
https://github.com/cloud-barista/cb-spider/blob/master/.github/workflows/docker-publish.yml
를 이용하는 방안도 있겠습니다.