Jost Do It!

상황Ubuntu에서 정상적으로 동작하던 ci script가 CentOS 환경에서는 permission denied 가 발생했다.  원인 Ubuntu에서는 디렉터리 읽기 권한이 있어 해당 디렉터리에 접근이 가능했지만, CentOS에서는 권한이 없어 접근이 거부된 것이다.  확인 과정은 아래와 같다.우선 .gitlab-ci.yml 파일에 echo $(whoami) 명령어를 통해 해당 스크립트를 실행하는 주체가 누구인지 파악했다.gitlab-runner 라는 유저로 runner가 실행되는걸 확인할 수 있다.  gitlab-runner 유저의 정보를 확인해보자.gitlab-runner는 자기자신 외의 다른 그룹에는 속해있지 않다.  Ubuntu 환경에서는 cd가 문제없었기 때문에 각 경로의 권한 확인을 진행했다..

상황gitlab runner 업그레이드 이후 ci/cd 과정에서 아래와 같은 에러가 발생했다.  커맨드와 스택오버플로우의 조언대로 아래 두 명령어를 사용해봤으나 동일한 에러가 계속 발생했다.git config --global --add safe.directory /home/mining/dockerfiles/clickhousegit config --global --add safe.directory '*'  소유권 에러 발생 원인우선 해당 에러는 git을 업데이트하면서 보안정책이 변경돼 발생한다.기존 git은 아래 두가지의 취약점이 존재했다.1. Window에서 git 사용 시 dll 확장자 파일이 git uninstall을 강제실행할 수 있는 문제2. 프로젝트들 경로 상위에 .git 폴더 생성 시 하위 프..

원인gitignore에 추가했더라도 git 서버에서는 기존 트래킹 파일들 내용을 저장하고 있기 때문에 발생한다. 해결방법다음 명령어를 통해 서버에 해당 파일에 대한 정보를 제거하고 다시 add 해준다.git rm -rf --cached example.txtgit add . ReferenceGitignore not working

문제 상황사내 gitlab 서버를 이전하면서 git 관련 명령(fetch, pull 등)을 하면 아래와 같이 server의 인증서 검증에 실패했다는 메시지가 발생했다.git fetch>> fatal: unable to access 'https://gitlab.xxxx.com/financial_backend/us_stock_processing/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none  그리고 해당 도메인으로 POST 명령 시에도 Peer's Certificate issuer is not recognized. 에러 메시지가 발생한다.curl -v https://gitlab..

문제 상황서버에 설치된 gitlab을 초기화 하기 위해 gitlab을 제거하고 다시 설치하는 중 다음 에러가 발생하였다.gitlab-ci-multi-runner: exit status 1Runtime platform arch=amd64 os=linux pid=2672 9 revision=535ced5f version=16.11.1FATAL: decoding configuration file: toml: line 54 (last key "runners.name"): ..

개요 .gitignore로 적용 시 기존에 원격 레포에 업로드된 파일들은 여전히 tracked 되고 있는 문제가 있었다. 해결 방법 .gitignore에 config 파일들을 등록했다. *.cfg *.config 이후 기존에 원격레포에 업로드 돼 있던 cfg파일들의 캐시를 제거해준다. git rm --cached test.cfg # 특정 파일만 제거 git add . git commit -m "remove cached file" git push origin master 전체 캐쉬를 삭제하려면 git rm -r --cached .으로 명령할 수 있다. gitignore 적용 파일 확인 다음 명령어로 .gitignore에 적용되는 파일 리스트를 확인할 수 있다. git status --ignored >> I..

문제 상황 gitlab에서 특정 브랜치에 Merge Request(MR)가 발생하면 특정 stage를 실행하려고 아래와 같이 코드를 작성하였다. stage1: stage: example rules: - if: $CI_COMMIT_BRANCH == "prod" && $CI_PIPELINE_SOURCE == "merge_request_event" script: - echo "hello world!" 그런데 MR 후에도 해당 stage의 코드가 실행되지 않았다... 다음과 같이 ci/cd 테스트 스테이지를 작성해서 변수 값이 뭘로 설정되는지 확인해보니 push로 나오는걸 확인했다. test_stage: stage: test script: - echo "$CI_PIPELINE_SOURCE" 문제 원인 처음에는 ..

문제 상황 성질이 다른 데이터에 대해 거의 비슷한 작업을 해야해서 기존에 작업했던 모듈을 copy해 작업했다. 기존에 작업했던 모듈들은 git submodule을 가지고 있는데 copy한 작업을 git에 올리니까 submodule로 인식이 안됐다. .gitmodules에는 submodule 경로와 url이 잘 잡혀있지만... push된 결과는 일반 레포로 잡힌걸 확인할 수 있다. git submodule status를 확인 해보니 기존 레포와 달리 서브모듈이 인식안되는걸 확인할 수 있었다 (결과가 안나옴). 원래 레포에선 이렇게 서브모듈에 대한 상태정보가 나온다. 원인 깃을 초기화하고 새로운 원격 레포에 push 하면 git은 submodule에 대한 정보를 알 수 없다. 즉, submodule에 대한 ..

깃은 디폴트(메인) 브랜치에서 여러 브랜치를 파생할 수 있다. 여러 브랜치로 파생하여 메인 브랜치의 내용들과 충돌 없이 파생된 브랜치에 코드 내용을 수정할 수 있다. 그리고 수정된 코드 내용들을 메인 브랜치와 통합할 때는 PR을 요청하여 깃헙 관리자가 이를 허용/거절하는 구조로 이루어진다. 그러면 이 브랜치를 어떻게 파생할 수 있을까? 깃 브랜치 생성 로컬에서 깃 브랜치를 생성하는 방법은 다음과 같다. 아래 명령어를 쉘의 로컬 깃저장소 위치에서 입력한다. git branch {생성할 브랜치명} 한편 메인 브랜치와의 충돌을 피하려면 메인브랜치의 최신 내용을 pull한 상태여야 한다. 이후에 브랜치에 커밋을 하여야 메인 브랜치와 충돌을 피할 수 있다. 깃 브랜치 변경 위 명령어는 로컬 깃 저장소에 새로운 브..

에러 내용 깃헙에서 workflow 내용을 수정하고 github 저장소에 push하니까 위 에러가 떴다. 내용은 다음과 같다. ! [remote rejected] {원격저장소 branch명} -> {원격저장소 branch명} (refusing to allow a Personal Access Token to create or update workflow `.github/workflows/code-style-check.yaml` without `workflow` scope) error: failed to push some refs to 'https://github.com/{원격저장소 링크}' 메세지 내용을 살펴보면 github에서 발급받은 개인 access token이 workflow를 수정할 수 있는 권한..