https://github.com/buildpacks/pack/pull/1741
예전에 SKTBrain의 KoBert 프로젝트에 Dependency 변경하는 걸로 Contributor 올라간 적은 있었는데,
좀 더 큰 규모의 프로젝트에도 소소하게 수정한 내용이 Contribution에 포함됐다.
진짜 별 거 아니지만, 진짜 별 거 아니라서 기록하는 내용.
"Contribution은 진짜 누구라도 할 수 있구나, 별 거 아니구나" 라는 글로 읽혔으면 좋겠다.
어쩌다?
회사 업무를 하면서 buildpack과 pack cli의 기능을 조사할 일이 있었다. 빌드 시간을 단축할 수 있는 방법을 찾아야 했기 때문.
pack으로 OCI Image를 생성하는 pack build 커맨드를 확인해보니, 아래와 같은 옵션이 있었다.
https://buildpacks.io/docs/tools/pack/cli/pack_build/
pack으로 빌드를 수행할 때 build / launch layer가 만들어지는데, 이 layer를 여러 빌드 프로세스에서 재사용할 수 있도록 하는 옵션이다.
바로 아래에 있는 cache-image 옵션보다 자유도가 높은, 비교적 최근에 만들어진 것으로 보인다.
- --cache-image: pack build에서 만들어진 build layer 에만 해당되며, input으로 OCI Registry path를 파라미터로 받는다.
--Publish 옵션이 반드시 필요하며, 아래 두 가지 기능을 수행한다.- Registry Path에 이미지가 있으면, 해당 이미지를 build layer로 재사용한다.
- 빌드 과정에서 만들어진 build layer image를 Registry Path에 push한다.
- --clear-cache 옵션이 default true이므로,
registry path에 이미지가 있을 경우 기존의 registry image를 delete & 새 이미지 push를 시도한다.
- --clear-cache 옵션이 default true이므로,
build layer를 캐시해서 재사용하는 건 좋은데 image path를 반드시 덮어쓰도록 하는 괴상한 형태의 옵션이라,
- build / launch layer도 구분되고
- OCI image만 강제하는 대신, 빌드하는 머신의 volume에도 캐시할 수 있다는 점에서
--cache 옵션이 활용도가 더 높아 보였다.
왜?
Docs에 소개된 옵션은 cli 명령어를 사용하는 방법이다.
우리는 go client를 사용하기 때문에, 해당 옵션이 정의된 go struct에서 옵션을 입력하는 식으로 사용할 수 있어야 했다.
그런데 pack go client에서 cache 패키지를 불러오지 못하고 있었다.
왜 이렇게 만들었는지 확인하려고 --cache 옵션이 추가된 pr을 확인해봤다.
https://github.com/buildpacks/pack/pull/1477/files
cache 패키지가 internal로 들어가 있었다.
go에서 internal 디렉토리 하위에 정의된 패키지는 프로젝트 외부에서 불러올 수 없게 되어 있다.
로직을 좀더 확인해보니, cli로 pack --cache 옵션을 넣을 경우
- cmd 로직에서 input parsing 해주고
- 프로젝트 내부에서 struct 생성하는 식으로 쓰고 있었다.
어떻게?
내가 아니어도 누군가가 문제제기를 했을 만한 버그라고 생각했다.
pack 진영에서 이미 문제를 인지하고 있을 거 같아서 community에 질문을 올려봤다.
https://github.com/buildpacks/community/discussions/213
issue 만들어 달라고 답변이 왔다. 비슷한 문제가 어떤 식으로 이슈 만들어졌는지 참고하라는 링크도 같이 왔다.
https://github.com/buildpacks/pack/issues/1709
그래서 issue를 만들어 올렸다. 어차피 패키지만 바꾸면 되는 거니까 오픈소스 진영에서 알아서 해결하겠지 싶었다.
근데 나보고 하라고 했다.
지금까지 Contribution 해본 적 없는데 어떻게 해야 하지? 싶었는데,
프로젝트의 CONTRIBUTING.md와 DEVELOPMENT.md 보니 정리가 잘 되어 있었다. makefile을 잘 만들어뒀다.
https://github.com/buildpacks/pack/blob/main/CONTRIBUTING.md
https://github.com/buildpacks/pack/blob/main/DEVELOPMENT.md
패키지 경로 바꿔주고, makefile 참고해서 prepare-for-pr 해주고 pr을 올려봤다.
추가로, DCO라는 것도 처음 알았다. Github Actions에서 DCO에서 Fail 발생하길래 조금 찾아봤다.
어떻게 해결하는지도 github action에 쓰여 있어서 해결은 아주 쉽게 했다.
https://github.com/buildpacks/pack/runs/13055903947
Commit을 수행한 사람이 누구인지를 github 계정으로 sign하는 개념이라고 이해했다.
https://probot.github.io/apps/dco/
PR 올리고 일주일 정도 있으니까 승인 후 main 브랜치에 머지되었다.
'일상 속 생각' 카테고리의 다른 글
2023.08.12. 두손갤러리 '바자전' Holi-day 전시 (0) | 2023.08.15 |
---|---|
2023.05.20 플랫폼엘 - Phantom Sense 전시 후기 (1) | 2023.05.21 |
2022.11.05 한국미술의 서사 - 두손갤러리 전시 (0) | 2022.11.05 |
CKA 자격증 합격 후기 + 준비했던 방법 정리 (5) | 2022.05.23 |
2022 마르크 샤갈 특별전 - Chagall and the Bible 전시내용 및 후기 (0) | 2022.01.28 |