工做須要,原先的一臺專門負責打包的機器要被調走,因此另起爐竈,把須要打包的項目遷移到新機器,本篇文章講述了遷移過程遇到的一些問題以及解決的方法。html
首先仍是簡單說一下什麼是gitlab-runner,官網是這麼描述的:git
GitLab Runner is the open source project that is used to run your jobs and send the results back to GitLab. It is used in conjunction with GitLab CI, the open-source continuous integration service included with GitLab that coordinates the jobs.docker
也就是說gitlab-runner是配合gitlab-ci進行使用的。通常地,gitlab裏面的每個工程都會定義一個屬於這個工程的軟件集成腳本,用來自動化地完成一些軟件集成工做。 當這個工程的倉庫代碼發生變更時,好比有人push了代碼或者分支合併,gitlab就會將這個變更通知gitlab-ci。這時gitlab-ci會找出與這個工程相關聯的runner,並通知這些runner把代碼更新到本地並執行預約義好的執行腳本。shell
安裝 註冊 這塊廢話很少說,直接看官方文檔,根據系統一次操做一下便可ruby
新機器到手後,把機器上全部的軟件環境通通更新了個遍,升級到macOS High Sierra,ruby 升級到2.4等等。而後開始安裝gitlab-runner緊接着註冊到gitlab-ci,一切的一切都看似很平靜很正常。bash
而後開始試跑腳本,而後莫名其妙的出錯了,log以下:編輯器
Running with gitlab-runner 10.3.0 (5cf5e19a)
on xxx的MacBook pro (0dee7c95)
Using Shell executor...
Running onxxxdeMacBook-Pro.local...
Cloning repository...
Cloning into '/Users/xxx/builds/0dee7c95/0/iOS-Team/xxx-test'...
Checking out 0766deb4 as develop...
Skipping Git submodules setup
ERROR: Job failed: exit status 1
複製代碼
clone以後立馬出問題,一臉懵逼...這誰看得懂出的啥錯?涼了涼了~函數
剛開始覺得是clone出問題,打開build的目錄文件,裏面全部文件目錄都是完整的,直接打開項目工程都能順暢的跑起來。 嘗試用這些log輸出,Google了一下,能搜到好幾個Stack Overflow的結果,可是很遺憾,都未能解決問題。工具
那麼問題到底出在哪?gitlab
首先的換一個思考問題的角度:gitlab-ci上的log看不出,搜不出什麼端倪,那麼gitlab-runner呢?畢竟跑腳本是gitlab-runner的事情,它本身最清楚了。
因而在打包機器終端裏面輸入gitlab-runner --debug run
這樣runner的每一步操做都能看的到。
Checking for jobs... nothing runner=0dee7c95
Feeding runners to channel builds=0
Checking for jobs... received job=402 repo_url=http://gitlab.xxxx.cn/iOS-Team/xxx-test.git runner=0dee7c95
Failed to requeue the runner: builds=1 runner=0dee7c95
Running with gitlab-runner 10.3.0 (5cf5e19a)
on xxx的MacBook pro (0dee7c95) job=402 project=47 runner=0dee7c95
Shell configuration: environment: []
dockercommand:
- sh
- -c
- "if [ -x /usr/local/bin/bash ]; then\n\texec /usr/local/bin/bash --login\nelif [ -x /usr/bin/bash ]; then\n\texec /usr/bin/bash --login\nelif [ -x /bin/bash ]; then\n\texec /bin/bash --login\nelif [ -x /usr/local/bin/sh ]; then\n\texec /usr/local/bin/sh --login\nelif [ -x /usr/bin/sh ]; then\n\texec /usr/bin/sh --login\nelif [ -x /bin/sh ]; then\n\texec /bin/sh --login\nelse\n\techo shell not found\n\texit 1\nfi\n\n"
command: bash
arguments:
- --login
passfile: false
extension: ""
job=402 project=47 runner=0dee7c95
Using Shell executor... job=402 project=47 runner=0dee7c95
Waiting for signals... job=402 project=47 runner=0dee7c95
WARNING: Job failed: exit status 1 job=402 project=47 runner=0dee7c95
Submitting job to coordinator... ok job=402 runner=0dee7c95
Feeding runners to channel builds=0
Checking for jobs... nothing runner=0dee7c95
複製代碼
以上的log是爲了復現問題,把相關配置改爲問題解決以前,而操做出來的,可能和問題解決以前的log有些出入。根據這些log,再次Google,果真找到了相關信息: https://gitlab.com/gitlab-org/gitlab-runner/issues/114 真相大白,原來問題出在RVM上。
RVM相信開發者都不陌生,它是一個便捷的多版本ruby環境的管理和切換工具。有一個注意點,MacOS自己是集成ruby環境的,不一樣版本的系統默認集成的ruby版本也不同。因此平常開發中,咱們會根據須要對ruby環境統一管理。這個時候就會用到rvm了。經過rvm能夠升級管理ruby。經過which ruby
命令能夠查看目前使用的是什麼ruby。好比/Users/xxx/.rvm/rubies/ruby-2.4.1/bin/ruby
輸出的路徑包含了.rvm
就說明目前使用的是rvm下的ruby。
到此爲止肯定了目前使用的是rvm的ruby,在深刻定位一下,問題是出在rvm從新定義了cd
命令
$ type cd
cd is a function
cd ()
{
__zsh_like_cd cd "$@"
}
$ unset cd
$ type cd
cd is a shell builtin
複製代碼
因此,clone下來一直出錯的緣由是cd命令被重定義了,致使路徑切換的不對,沒法執行命令,進而報錯。這就解釋了爲何gitlab-runner上輸出的log exec /bin/sh --login\nelse\n\techo shell not found\n\texit 1\nfi\n\n
知道了緣由name如何解決呢?剛剛的問題裏面也給出了方案 在.bashrc
或 .bash_profile
加上unset cd
。 操做以下:
一、打開terminal(終端)
二、cd ~ ( 進入當前用戶的home目錄)
三、open .bash_profile (打開.bash_profile文件,若是文件不存在就 建立文件:touch .bash_profile 編輯文件:open -e bash_profile)
四、直接更改彈出的.bash_profile文件內容
五、command + s 保存文件,而後關閉
六、在terminal(終端)中輸入 source .bash_profile (使用剛纔更新以後的內容)
複製代碼
或者直接finder裏面找,用文本編輯器修改一下。
等等.bashrc
.bash_profile
又是什麼鬼? unset呢? 百度了一下這些獲得以下信息: profile\bashrc\bash_profile之間的區別和聯繫:
/etc/profile 每一個用戶,首次登陸時被執行; /etc/bashrc 每一個運行bash shell的用戶都執行此文件,當bsh被打開時,該文件被讀取; ~/.bash_profile 專用於本用戶的shell信息,僅被執行一次; ~/.bashrc 文件包含本用戶的bsh信息,登陸及每次打開shell時被讀取。
unset指令:刪除指定的shell變量或函數 【語 法】unset [-fv][變量或函數名稱] 【功能介紹】該指令做用主要是刪除指定的shell變量和函數。
由於gitlab-runner註冊的時候runner executor用的shell,因此shell腳本的語法是適用的。使用unset cd
就意味着把rvm從新定義的cd方法刪除,這樣路徑切換的時候就正常了。gitlab-runner都能正常跑起來了。
1.思考問題角度要全面,一套完整的業務流程裏出現問題,能夠根據不一樣角度,不一樣端想錯誤點靠近,逐個的排查; 2.多關注debug信息,活用debug輸出的log搜索信息,儘可能谷歌搜索,百度太垃圾; 3.shell腳本是個神奇的東西,工做之餘能夠多學習學習。