GitLab의 이름이 변경된 프로젝트로 계속 리다이렉트될 때

GitLab의 이름이 변경된 프로젝트로 계속 리다이렉트될 때

주의

들어가기 앞서, 이 글은 GitLab 호스팅이 아닌 GitLab 설치형 또는 옴니버스 기준으로 작성됨을 알린다.

리포지토리 이름 및 경로 변경

GitLab에서는 리포지토리의 이름을 바꾸거나 경로를 바꿀 수 있다. 이름만 바꾼다고 경로까지 바뀌지는 않고, 각각 따로 바꿀 수 있다.

리포지토리 이름 변경

리포지토리의 이름을 변경하려면 리포지토리의 Settings - General로 이동하여 Naming, topics, avatar 섹션을 열고 Project Name을 변경하면 된다.
리포지토리 이름 변경

리포지토리 경로 변경

하지만 리포지토리 이름을 변경한다고 해서 리포지토리 경로가 바뀌진 않는다. 예를 들어 기존에 https://honsal.io/honsals/HsStringTools 경로로 접근할 수 있었던 리포지토리의 이름을 HsStringTools에서 HsStringToolsLegacy로 변경한다고 해서 URL이 https://honsal.io/honsals/HsStringToolsLegacy로 변경되지는 않는다는 말이다.

이걸 변경하려면 마찬가지로 Settings - General로 이동하되 이번엔 Advanced 섹션에서 작업해야 한다.
경로 변경

경로 변경은 Change path 버튼을 누르면 적용된다.

리다이렉트 문제

내 생각에 대부분의 상황에서는 이렇게 하고 나서 아예 잊어버려도 아무런 문제가 없을 것이다. 심지어 기존 프로젝트 구성원에게 경로가 바뀌었으니 URL을 다르게 적용하라고 말하지 않아도 아무런 문제가 없을 것이다.

왜냐하면 GitLab이 (GitHub이 그렇듯이)변경되기 전 경로를 자동으로 변경 후 URL로 리다이렉트하기 때문이다.

문제는 리다이렉트하지 말아야 할 때

하지만 내 경우에는 이게 문제가 되었다. 이 GitLab 인스턴스는 사실상 내 프리랜서 개발 용도로 혼자 쓰다시피 하고 있기에 이슈 관리보다 버전 관리에 더욱 치중된 채 운영되고 있다.

그리고 이번에 거의 5년이 넘게 방치되고 있던 스무 개 가량의 레거시 닷넷 프레임워크 프로젝트를 아카이브하고 .NET 7 버전으로 올린 새로운 프로젝트를 푸시하려다가 사건이 발생하게 되었다.

푸시가 안 된다!

푸시가 안 된다. 정확히는 자꾸 리네임된 레거시 프로젝트로 리다이렉트되어 새로운 리포지토리를 동일한 URL에 푸시할 수 없다.

지금 내가 하고자 하는 일은 다음과 같은데,

레거시 프로젝트명 기존 URL 새 레거시 프로젝트명 새 URL .NET 7 프로젝트명 .NET 7 URL
HsStringTools honsals/HsStringTools HsStringToolsLegacy honsals/HsStringToolsLegacy HsStringTools honsals/HsStringTools
HsNetworkTools honsals/HsNetworkTools HsNetworkToolsLegacy honsals/HsNetworkToolsLegacy HsNetworkTools honsals/HsNetworkTools
… … … … … …

즉 .NET Framework로 작성된 기존 리포지토리명의 뒤에 모두 Legacy를 붙여버린 뒤 아카이브하고, .NET 7으로 변환한 새 프로젝트를 기존 명칭으로 푸쉬하려 하는 중이다.

그러나 GitLab이 자동으로 생성한 리다이렉트 때문에 프로젝트명과 경로를 모두 바꿨음에도 새 프로젝트를 해당 경로로 푸쉬할 수 없는 상황이다.

게다가 UI에서 이를 지울 방법을 찾을 수가 없다.

해결 방안: GUI에 없다면 CUI로

어쩌겠는가. 사이트에 기능이 없으면 콘솔을 쓰는 수밖에. 다행히도 이러한 리다이렉트 관계를 정리한 RedirectRoute라는 클래스가 rails console에 정의되어 있다.

우선 다음과 같이 도커 gitlab 인스턴스에서 gitlab rails를 실행하였다.

 docker exec -it gitlab gitlab-rails console -e production

그리고 RedirectRoute.all로 현재 리다이렉트 테이블을 확인해봤다.1

irb(main):001:0> RedirectRoute.all
=>
[#<RedirectRoute:0x0000????????????
  id: 1,
  source_id: 1,
  source_type: "Namespace",
  path: "root",
  created_at: Tue, 02 May 2023 21:40:43.281860000 KST +09:00,
  updated_at: Tue, 02 May 2023 21:40:43.281860000 KST +09:00>,
 #<RedirectRoute:0x0000????????????
  id: 2,
  source_id: ??,
  source_type: "Project",
  path: "SENSORED",
  created_at: Tue, 13 Jun 2023 09:27:19.330506000 KST +09:00,
  updated_at: Tue, 13 Jun 2023 09:27:19.330506000 KST +09:00>,
 #<RedirectRoute:0x0000????????????
  id: 3,
  source_id: ??,
  source_type: "Project",
  path: "HsStringTools"
  created_at: Mon, 04 Dec 2023 01:10:09.283365000 KST +09:00,
  updated_at: Mon, 04 Dec 2023 01:10:09.283365000 KST +09:00>]
 
irb(main):002:0>

id: 3에 문제의 프로젝트 경로가 보이는 것을 확인할 수 있다. 이걸 지우면 문제가 해결된다. 주의할 점은, 어떠한 경고나 저장 과정 없이 즉시 실행되고 반영되기 때문에 id가 일치하는지 꼼꼼히 확인해야 한다.

irb(main):003:0> RedirectRoute.find_by(id: 3).delete
=>
#<RedirectRoute:0x00007fdc1faf6c40
 id: 3,
 source_id: 69,
 source_type: "Project",
 path: "honsals/HsStringTools",
 created_at: Mon, 04 Dec 2023 01:10:09.283365000 KST +09:00,
 updated_at: Mon, 04 Dec 2023 01:10:09.283365000 KST +09:00>
irb(main):005:0> RedirectRoute.find_by(id: 3)
=> nil

이제 새 리포지토리를 원래의 경로로 푸시할 수 있다.

결론

GitLab은 GitHub과 같이 프로젝트의 경로가 수정되면 기존 경로가 수정된 경로로 자동으로 리다이렉트되도록 라우팅 테이블을 생성한다.

적어도 내가 확인한 바로는 이러한 라우트 테이블을 프로젝트 설정이나 인스턴스 설정 등 사이트 내에서 수정/삭제할 수 없기 때문에 gitlab console을 사용하여 직접 삭제해야 한다.

해결 방법을 알아보던 중 관련 이슈를 몇 개 봤는데, 죄다 수 년동안 반영되지 않은 걸 보면 (내가 못 찾은 게 아니라면)이런 기능은 구현되지 않지 않을까 싶다.

  1. 내 경우엔 리다이렉트 된 리포지토리가 많지 않기에 이 방법을 썼으나, 규모가 있는 환경이라면 RedirectRoute.find_by 등을 사용하면 된다. ↩︎

댓글

댓글 쓰기

이 블로그의 인기 게시물

C# 남아도는 메모리에도 불구하고 OutOfMemoryException이 발생한다면?

이미지
  C# 코딩 중 평소 볼 수 없던 생소한 현상이 발생했습니다. 분명 메모리는 남아도는데(32기가바이트 중 26기가바이트 사용 가능) 프로그램이 돌다가 OutOfMemory 예외를 던지며 죽어버리는 현상이었죠. List 에 수많은 파싱된 데이터를 넣는 작업 중이었습니다.   그래서 메모리 프로파일러를 잘 관찰해보니 2GB의 메모리를 사용하면 무조건 뻗어버리는 현상을 발견했고, 왜 그럴까 생각해보다가 문득 예전 XP에서 4기가 메모리를 달아도 32비트 운영체제의 한계 아닌 한계로 3기가 조금 넘게밖에 인식을 못 했던 것이 생각났습니다. 생각은 자연스럽게 컴파일이 32비트로 됐구나! 쪽으로 넘어갔고 프로젝트 설정에 보니 빌드 항목에 해당되는 체크박스가 있더군요.   현재 메모리가 남아도는데도 OutOfMemory 예외가 뜬다면 100% 저게 체크된 상태일 겁니다. 그림과 같이 체크 해제 하신 후 실행하시면 특별한 경우가 아닌 이상 컴퓨터 메모리가 바닥날 때까지 저 예외를 볼 일 없게 될겁니다.
자세한 내용 보기

MySQL 데이터 타입과 Java 데이터 타입 비교/매칭

  안녕하세요? 혼살입니다. 블로그에 정말 오랜만에 글을 씁니다. 일하고 겜하고 일하고 겜하고 집에 박혀서 매일 똑같은 일상을 보내다 보니 블로그에 글을 오랫동안 안 쓰고 있었네요. 대부분 근황은 유튜브 동영상으로 대체하다 보니 더욱 더 그랬던 것 같습니다.   하지만 이번엔 영상보다 글로 남기는 게 더 유익할 것 같아 간만에 글을 쓰게 되었습니다. 바로 MySQL Data Types & Java Data Types 매칭! 현재 진행중인 외주 작업 중 SET 타입을 Java에선 어떻게 처리하나 찾아보다가 잘 정리된 블로그 글 을 발견해 나중에 손쉽게 찾기 위해 제 블로그에도 씁니다. 위 링크에 들어가시면 테이블로 잘 정리돼 있으니 한 번 들어가 보시는것도 괜찮겠네요. 왼쪽은 MySQL, 오른쪽은 Java의 데이터 타입입니다. BIT <-> Boolean TINYINT <-> Integer BOOL/BOOLEAN (TINYINT(1)) <-> Integer SMALLINT <-> Unsigned 상관없이 Integer MEDIUMINT <-> Integer, Unsinged라면 Long INT <-> Integer, Unsigned라면 Long BIGINT <-> Long, Unsigned라면 java.math.BigInteger FLOAT <-> Float DOUBLE <-> Double DECIMAL <-> java.math.BigDecimal DATE <-> java.sql.Date DATETIME <-> java.sql.Timestamp TIMESTAMP <-> java.sql.Timestamp TIME <-> java.sql.Timestamp YEAR <-> yearsIsDateType이 설정됐다면 java.sql.Date, 아니라면 Short CHA
자세한 내용 보기

테일즈위버 OST 전곡 모음

이미지
  블로그를 옮기면서 카드캡터 사쿠라 OST를 포함해 테일즈위버 OST 역시 까먹고 안 옮겼었네요. 소름... 블로그 조회수의 대부분을 차지하는 두 개를 안 옮겼었다니!   게임보다 OST들으러 들어간다는 테일즈 위버(Tales Weaver)의 모든 OST 모음집입니다. FLAC파일을 재생할 수 있는 플레이어가 필요합니다... 만 요새는 웬만해선 다 재생해주죠. 즐감하세요.
자세한 내용 보기