...
본문 바로가기

Xcode

오픈소스 기여해보기 (feat Tuist)

 

누구나 개발자라면, 오픈소스 기여해봐라 라는 얘기를 줄곧 들어봤겠지만..

나랑은 다른얘기라고 생각했었는데, 어쩌다보니 Tuist 라는 오픈소스에 기여하게되었다(?)!

(참고로 개발자 3년차 입니다)

 

 

이번글의 취지는 누구나 오픈소스 기여해볼수있다라는 것과 ( 저도 했으므로.. )

생각보다 쉬울 수 있다는 것!!을 말하고싶다. 

먼저 말하지만, 나의 풀리퀘는 엄청난게 아니라, 정말 사소한 이슈 수정이라, 사소한것도 될수있다! 

 

아래 내용은 내가 어떻게 오픈소스에 기여하게되었는지를 작성했다. 

 

발단

요즘 Tuist를 공부하고있고, Tuist 마이그레이션 후기 글을 작성했었다.

원래는 오픈소스에 기여하겠다는 생각이 전혀 없었는데,

마이그레이션 하면서 궁금했던 부분을 xcconfig를 이용했을때, Tuist에 의해 오버라이딩 되는 케이스 라는 글을 올렸다. 

이게 시작이었다...

더보기

 

그냥 간단하게, 사실 Settings에 딕셔너리로 추가해주면 되는데, xcconfig를 사용하는데, 어떤키에 대해서는 예외처리를 해줘야한다는게 나는 일관성이 없다라고 생각했다. 그래서 Settings에 딕셔너리를 추가해주는 방법말고 다른 방법을 찾고있었고,

 

대부분  https://github.com/tuist/tuist/issues/954 , https://github.com/tuist/tuist/issues/5265#issuecomment-2093433967 이방법을 통해서 해결을 했다.

요지는, Settings의 defaultSettings에 .none으로 하면 tuist에서 생성되는 값들이 오버라이딩 되는것을 어느정도 방지할수있고,

그럼에도 안되는 케이스에 대해서는, Target에 프로퍼티로 있는 케이스로, 해당 프로퍼티에 다음과 같이 사용하면 됐다.

Target(
    // ...
    bundleId: "${CUSTOM_BUNDLE_ID}",
    // ...
),

 

하지만 그럼에도 불구하고, 오버라이딩이 되는 케이스가 있었는데...

그것은 unitTest타겟의 TEST_HOST의 값이였다.

요건 어떤 방법으로도 해결이안됐었고, 그래서 Tuist커뮤니티에 글을 올렸다. 

 

답변이 달렸는데, 버그로 보인다고 한다! (marekfort 느님.)

게다가 친절하게 Tuist에서 Settings를 생성하는 코드위치까지 알려주셨다. 

 

중간에 나를 이끈 단어가 있었는데..  너가 수정해볼래~? 도와줄게~^^

 

 

그래! 나도 이제 개발자 3년차. 꽤나많이 디버깅도 많이해봤으며, 버그가 발생하면 꽤나 원인을 잘 찾아냈다. 

나도 코드를 볼줄아니까 내가 한번 해봐야겠다!! 라고 생각했다.

 

 

Tuist 클론 

이제 소스코드를 받아서 실행을 해봐야한다. 

https://docs.tuist.io/en/contributors/get-started

 

Get started - Contribute to Tuist

 

docs.tuist.io

여기에 클론하고, 실행하는 방법이 나와있다. 

 

tuist generate 명령어를 이용하면 프로젝트가 생성되는건데, 

이번에는 소스코드를 받아서 실행하는거니까, 

tuist에서는 terminal target 으로 실행하게 한것 같다. 

적절히 알려주는대로, 스킴에 argument 추가해주고, 프로젝트 생성하고자하는 디렉토리 경로도 설정해주었다.

( 이런방식이 처음이라 낯설긴했다. )

 

오! 소스코드로 실행하여 프로젝트를 생성해주었다!! 

 

 

과정

진입점부터 찾아보고, 디버깅해보면서 어디에서 실행되는지 보고했다.

Settings를 설정해주는곳까지 브레이크걸어보면서 찾아가려고 했지만, 코드가 너~무 많아서 

marekfort 느님이 알려주신 코드로 가서 그 근처를 봤다. 

 

코드를 보니, TEST_HOST를 직접 만들어주고 있었고, 

해당 호출전에는 기본적으로 세팅해주는 코드들도 확인할 수 있었다. 

 

아이디어는, 기본적으로 세팅해주는 코드들에서도 Settings의 defaultSettings를 참조하여, excluding이 있거나, none인경우에는 넣어주지 않고 있었다. 

TEST_HOST도 그렇게 해주면 될거라고 생각했다. 그렇게 코드를 수정했고, 테스트코드도 작성해주었다. 

 

또 내가 변경한 코드로 인해 다른 이슈가 없어야하므로, 테스트도 싹 돌려주었다.  모두 success!! 

이제 PR을 올려본다! 

 

Issue 등록 

marekfort 느님이 이슈로 먼저올리라고 하셨고, PR에 이슈연결하는게 좋을듯하여, 

issue를 먼저 등록했다. 

https://github.com/tuist/tuist/issues/6888

 

Tuist overrides the TEST_HOST build setting for UnitTest targets, even when using xcconfig. · Issue #6888 · tuist/tuist

What happened? While configuring a project using Tuist 4.30 (It was happend in Tuist 4.26 also), I encountered instances where xcconfig values were overridden by Tuist. If a key in the build settin...

github.com

 

 

PR 올리기 

 

최대한 기존 컨벤션에 맞추려고했다. 커밋내역도 보면서 어떤식으로 작성하는지 보고, 

브랜치따로 만들어서 커밋하여 PR을 올렸다. 

 

https://github.com/tuist/tuist/pull/6889

 

Respect overriding the TEST_HOST build setting by gustn3965 · Pull Request #6889 · tuist/tuist

…, even when using xcconfig. Resolves #6888 Short description 📝 Fix Tuist overrides the TEST_HOST build setting for UnitTest targets, even when using xcconfig. Concerns: If this issue fix is imple...

github.com

 

PR작성하면서 체크리스트도 있길래 다 보고 체크했다.

( 사실 PR이 한번에 성공한건 아니고, 처음 PR에서 자동화단계에서 lint가 실패했다. 

그래서 이번기회에 swiftlint, swiftformat도 설치해보고 다음 커밋들은 lint도 해보고 올렸다 )

 

 

첫 PR올릴때가지 5시간이 걸렸다..ㅋㅋ 별거아닌걸로 삽질도 좀 하고...  ( 새벽다섯시에 잤다 )

 

 

리뷰보고 다시 커밋 

forttmarek 느님이 리뷰를 해주셨다!!!

 

 

사실 그동안 경험으로 인해 버그수정을 하면서 오히려 다른 이슈가 발생하는 적이 많기에, 코드수정에 조심스럽게 접근하는 경향이 있었다. 그럼에도 메소드위치 자체를 바꾸거나, 크게 수정해야한다면 그만큼 더 많이 코드를 보고 수정했었다.

이번 Tuist도 조심스럽게 접근하려고 했었다.

내가 수정한건 기존코드에 예외처리를 해준것인데, 이것보다 더 진취적으로? 메소드위치 자체를 옮기는게 더 가독성있어보인다고 하셨다. 

 

또 마지막 부분에는 아주.... 친절하게 "하지만 GraphTraverser도 필요할거야~" 라고 말씀주셨다. 

날 완전 어린애로 보는것 같았다. 하지만 좋았다.(?)

 

 

 

 

머지성공

 

그렇게 리뷰에 기반하여 코드를 수정했고, 

한번더 리뷰를 받고, 한번더 커밋하고, 머지해주셨다!

 

 

 

후기

오픈소스 기여해보라는 말이 쉬우면서도 누군가에겐 어렵게 느껴진다. 

그렇다면, 강박적으로 오픈소스 기여에 목적을 두기보다는,

내가 사용하는 오픈소스에서 이슈가 있는지, 이슈가 있다면, 이걸 내가 수정해볼까? 로 접근하는게 맞는것 같다!

 

Tuist라는 오픈소스에 대해 굉장히 인상깊었다. 아주 대단하고, 나에게 귀감이 될것 같다. 

테스트코드가 있고, 깃헙에도 자동화로되어있으니, 왜 오픈소스가 잘 운영될수있는지 ? 를 느꼈던것 같다. 
테스트코드가 많이 있으니, 버그수정등에 있어서 검사가 가능하니, 수정하는 입장에서도 굉장히 안정감을 느꼈다. 
테스트코드와 자동화덕분에 풀리퀘가 단순히 리뷰받는것 그이상으로 느껴졌다. 
테스트코드 실행 자동화, lint 검사, SPM 빌드까지 자동화가 액션으로 이루어지는게 너무 좋았다. 

 

또, 이슈를올렸을때, 굉장히 친절하게, 반갑게 맞이해주는게 인상적이였다.
오 이거버그같아! 이런쪽이 문제일것같아, 근데 너가 한번 해볼래?! 이런식이여서 
내가한번해볼까...? 하는 생각이들었고, 결과적으로 기여하게 되었다. 

모든 오픈소스가 이렇진 않겠지만, 굉장히 내가 지향해야하는 부분이 아닐까 싶다. 

 

리뷰어에 맞춰서 코드수정했는데, 테스트케이스들도 수정이 필요했고, 코드중복을 줄이려고 메소드로 하나만들었는데, 리뷰어는 이 코드가 많은 코드를 줄여주는것으로 보이지않는다며, 오히려 간접성만 생기는것 같다라는 리뷰를 해주셨다. 
그동안 코드중복은 줄이는게 좋다라고 생각해왔는데, 다른관점을 갖게된것 같다. 

 

 

내코드가 머지될때까지 정말 즐거웠다. 

처음보는 사람이 내 코드에 리뷰를 성실하게, 그것도 아주 친절하게, 애기다루듯이 해주니까 다음 리뷰만을 오매불망 계속 기다렸다. ㅋㅋ

사실상 이번 이슈에 대해 해결한 부분에 대해서 나의 역할은 3할정도 같다. 나머지 7할은 forttmarek 느님이 다 디렉팅을 해주신것 같다.ㅎ 오히려 이분은 관리자의 입장에서 나같은 병아리가 참여할수있도록 도와주는것에 대해 즐거움을 느끼시는 분이 아닐까? 라는 생각마저 들었다. 

프로필까지 들어가서 보니, 사람 자체가 사람을 좋아하시는것 같다. 너무 멋지다.