OSS(Hasura)에서 처음 편집을 해서 정리를 해봤어요.

개시하다
최근 OSShasura/graphql-engine에서 편집이 수행되었습니다.
이 보도는 업무 중에 OSS 오류가 발생한 것부터 Issue 및 Pull request에서 버그를 보고하고 수정한 과정까지 간단하게 요약하였다.
지금까지 나는 OSS의 발행 난이도가 매우 높다고 생각한다.하지만 실제로 해보니 생각보다 문턱이 낮았고 경험치도 많이 얻었다.
OSS 콘서트를 하고 싶지만 아직 한 발짝도 내딛을 수 없다
이 사람들의 참고가 될 수 있도록 이 글을 썼습니다.졸렬한 글이지만 참고가 됐으면 좋겠다.
독자 대상
• OSS 이벤트에 참여하고 싶은데 어떻게 하는지 모르는 사람
하수라를 투시하고 싶은 사람
구성 내용
다음과 같이 Issue Pull Request가 설정되어 있습니다.
업무 중에 HasuraGraphiQL 서버에 첨부된 CLI(Go제)의 버전을 업그레이드한 후 특정 명령의 옵션이 움직이지 않았다.
구체적으로 Hasura의 웹 콘솔을 시작하는 명령

hasura console --address XXX

마이그레이션에 사용할 API 엔드포인트--address를 지정하는 옵션은hasurav2입니다.1.0으로 새롭게 추가된 베타 에디션--api-host 옵션이 추가되면서 이동이 불가능해졌다.
몰수까지의 노정
문제 발생~Issue 만들기
웹 검색에서 기사 찾기
이번에 발생한 버그에서 잘못된 정보가 나왔다.그래서 나는 먼저 잘못된 정보를 복사한 후에 홈페이지에서 보도·이슈에 맞는 내용이 있는지 검색했다.
오류 메시지:

Hasura console is not able to reach your Hasura CLI instance...

(Hasura CLI 인스턴스에 연결할 수 없음) 하지만 적절한 정보를 찾을 수 없습니다.
어느 정도 규모가 큰 OSS에서는 한 개의 오류도 맞히지 못했다.
문제가 발생했을 때, 버전이 막 업그레이드되었기 때문에, 최신 버전에서 발생했을 수도 있다고 가정합니다.검증을 위해 이전 버전으로 되돌아간 후 문제가 없고 정상적으로 실행되기 때문에 최신 버전의 행동만 가능합니다.
참고:
· 일정 규모의 OSS(Giithub Star 수 25k~)에서 구체적인 내용 정보를 뱉는 오류에 대한 이슈나 글을 발견하는 경우는 드물다.
• 인기가 없을 때는 최신 버전 특유의 문제가 아닌지 의심한다.
재현 조건의 조사
어느 정도 조사해 해결책을 찾지 못했기 때문에 하수라에 아이슈를 세우는 것을 고려했다.Issue에서 오류를 보고할 때 재현 조건을 기술해야 하기 때문에 어떤 조건에서 문제가 발생했는지 조사했습니다.
문제가 발생하면 명령은 다음 몇 가지 옵션을 통해 실행됩니다.

hasura console --console-port XXX --api-port XXX --address XXX --no-browser --admin-secret XXX

그중에 뭐가 고장이 났는지 조사하기 위해서.

옵션별로 제공

여러 옵션 조합

의 경우 --address 판명 옵션이 작동하지 않습니다.
참고:
· 문제 재현 방법이 기재되지 않은 오류 보고를 해도 OSS 관리자가 곤란할 수 있으므로 가능한 한 재현 가능한 상태를 조사한 후 이슈를 만듭니다.
・재현 방법을 조사할 때 먼저 간단한 가설부터 시도한 다음 천천히 조합을 시도한다.
Issue에서 Pull Request로 생성
Issue 만들기
문제의 재현이 완성된 만큼 하수라에 이슈를 투고하려 한다.
하수라의 이슈에 버그 보고용 템플릿이 있으니 그걸 따라 이슈를 쓸게요.

하수라의 예로는 다음과 같은 기술항목(한 예)이 있다.

Version Information: 버전 정보

What is the expected behaviour?:기대하는 행동은?

What is the current behaviour?:당신은 어떤 행동을 하고 있습니까?

Any possible solutions?:회피책이 있습니까?

오류를 일으킨 소스 코드 읽기
Issue 템플릿에서
Can you identify the location in the source code where the problem exists?(도원 코드의 어디에 문제가 있는지 아십니까? ※ 알고 있다면)
이런 기술 항목이 있다.
Issue는 소스 코드에 문제가 있는지 확실하지 않은 경우에도 설정할 수 있습니다.다만, 이번에 문제가 발생한 하수라 CLI는 자신이 평소 사용하던 고(Go)로 썼기 때문에'평소 고(Go)로 쓰면 읽을 수 있지 않을까'라는 생각에 소스 코드를 읽어보기로 했다.
다만, 아무런 단서도 없으면 읽을 수 없다.(난 장작 엔지니어니까...)따라서 다음과 같은 방법으로 코드리딩을 진행하기로 했습니다.

최신 버전에서만 발생한 문제이므로 조사최신 버전으로 변경, 관련 파일 찾기

문제가 발생한 --address 옵션과 관련된 코드를 중심으로 고장 원인을 조사

원인을 따지다
이렇게 읽으면 버그의 원인 코드를 확인할 수 있습니다

--address 새로 추가된 옵션 매개 변수를 통해 지정한 옵션을 변경할 때의 행동

이런 가설.수정된 코드로 구축과 테스트를 시도해 보면 문제가 생기지 않고 자신의 가설이 정확하다고 확신할 수 있다.
참고:
・ Issue 템플릿이 있으면 OSS 템플릿을 따라 Issue를 만듭니다.
・읽지 않은 소스 코드를 처음부터 이해하기 힘들기 때문에 파일 이름, 버전의 차이 등에 착안하여 읽는 범위를 좁힌다.
Pull Request에서 Merge로 제작
방침의 결정을 수정하다
소스 코드에서 문제가 확인되었으므로 Pull Request를 만듭니다.
이번 문제를 수정하기 위해degray를 일으키는 새로운 옵션과 지금까지 이동한 옵션이 모두 지정된 경우의 행동을 결정할 필요가 있습니다.
이에 따라 관리자에게 Issue에서 지침 문의부터 수정한다.
간호 방법의 조사
창고를 포크 후 분할...이와 같은 OSS 발매 절차는 다른 사람의 기사를 읽으면서 진행되고 있다.
OSS에 따라 제출 정보와 지점 명칭을 규정하는 스타일 가이드도 있기 때문에 적절하게 협조해야 한다.또한 수정 대상인 하수라 CLI는 E2E 테스트를 통과해야 하므로 자동 테스트 합격을 손 옆에서 확인한 후 Pull Request를 보냅니다.
Merge
push 후 mentena의 평론을 기다리세요.긴급도에 따라 댓글이 달릴 때까지 시간이 차이가 있지만 이번에는 반나절 정도다.
이후 관리자와 여러 차례 사소한 코드와 Pull Request 이름의 수정 교환을 하여merge를 얻었다.
하수라의 경우 표시가 되면 미니가 춤을 춘다

이렇게 되면 일련의 오류 보고~수정이 끝났다.
아마도 다음 버전의 수정이 발표될 것이다.
돌아보다
원본 코드의 변경은 몇 줄 정도밖에 되지 않아 오류 발견부터 수정까지 상당히 어렵다.
아래의 결점을 총결하였다.
· 최초 무관한 웹 기사, Stack OverFlow, 이슈에 끌려 수사에 혼란
• DeepL로 번역해도 일본어(주어, 술어 등을 명확히 함)로 제대로 번역하지 않으면 전달할 수 없음
영어 능력 부족
영어 능력 부족
말은 그렇지만 반성점 위에서 좋은 경험을 많이 얻었다.
· OSS의 소스 코드는 의외로 읽을 수 있다
· 다음 OSS 활동의 난이도는 대폭 하락
• 영어가 서툴러도 정확한 소스 코드와 열정만 있다면 방법이 있을 거야
감사를 받다
끝말
한번 써 보았는데, 이 문장은 단지 체험담을 한 번 서술했을 뿐이다.
OSS 활동 같은 건 대단한 엔지니어만이 할 수 있다고 생각했고, 이번 경험을 통해 OSS는 나에게 더욱 가까워졌다.
자신처럼 아무리 작은 일이라도 OSS에서 활동하는 사람이 많을수록 소프트웨어 업계 전체에 이익이 될 것이다.
전에 안 해본 사람이라도 기회가 된다면 꼭 해보세요.