簡體   English   中英

在 mac OS 上從 crontab 發出運行 git pull 命令

[英]Issue running git pull command from crontab on mac OS

我正在嘗試使用 crontab 自動運行 git pull 命令。 我在 MacOs 機器上。 Git 當我在沒有 cron 的情況下使用它時,pull 工作正常,但在 cron 中出現錯誤。 我已經嘗試了各種解決方案。 其中一些在下面。 他們都手動工作正常。

我嘗試將以下命令放入腳本 automate.sh 中,然后使用 cron 運行它。

  1. ssh-agent bash -c 'ssh-add /Users/{username}/.ssh/id_rsa; /usr/bin/git pull'

  2. eval `ssh-agent -s` && ssh-add ~/.ssh/id_rsa && ssh-add -l && git pull

但我總是低於錯誤,

fatal: could not read Username for 'https://git.{domain}.com': Device not configured

為什么?

我認為問題在於您需要的引號 嘗試在沒有括號的變量周圍使用雙引號( {} )

ssh-agent bash -c 'ssh-add /Users/'"$username"'/.ssh/id_rsa; /usr/bin/git pull'

注意:變量domain相同

看看這個問題

TL;DR:如果可以,請使用 ssh URL。 (並且:不要從腳本運行git pull 。)

您在此處顯示的URL ,來自您的錯誤消息:

https://git.{domain}.com

不是ssh (安全外殼)URL。 它是一個 HTTPS (HTTP-over-SSL) URL。 這是兩種完全不同的協議。 它們通常在不同的 IP 端口上運行(ssh 為 22,https 為 443)。 並非所有 Git服務器都響應這兩種協議,但如果您的服務器響應,則您的 Git 作為客戶端存在兩個關鍵差異:

  • Git 作為客戶端,通過https://連接,必須向服務器提供兩項:用戶名密碼 (密碼不必是文字密碼,例如可以是 PAT。)

  • Git 作為客戶端,通過ssh://連接,必須向服務器提供兩項:用戶名和某種密鑰

除了“密鑰”與“密碼”,它們看起來——實際上——非常相似,但 https 和 ssh 客戶端以完全不同的方式獲取這兩個項目:

  • https 客戶端通常直接從用戶的鍵盤讀取用戶名和密碼,繞過所有重定向嘗試。

  • ssh 客戶端通常將用戶名作為參數,並從公共和/或私有密鑰對文件中讀取密鑰和/或從代理獲取密鑰。

這兩個要點中的單詞通常做了很多繁重的工作,但這就是您看到的錯誤的原因。 當您從 cron 作業運行git pull沒有鍵盤可以讀取. 這是物理不可能的cron -這,而你甚至不是可運行的計算機有你用戶名和密碼輸入 在 Mac 上嘗試打開/dev/tty導致Device not configured錯誤。

收到該錯誤后,libCURL 庫1放棄並且整個拉取失敗。

現在,請注意ssh參數中獲取用戶名——而不是讓你輸入它——並從文件和/或ssh 代理中獲取密鑰,而不是讓你輸入它。所以 ssh 已經非常強大了這里的優勢:它不需要您坐在鍵盤前,准備好需要輸入用戶名和密碼。 因此,如果您讓 Git 使用 ssh, 2您更有可能繼續。

這不是答案的結束(盡管這是開始,因此是上面的 TL;DR)。 使用 https 時,您可以告訴 libCURL不要從用戶那里讀取用戶名和密碼。 具體如何操作取決於操作系統,但一般來說,您可以使用以下形式的 URL:

https://user@host:password/path/to/repo.git

這樣做的缺點是您將用戶名和密碼以明文形式放在那里供所有人查看。 避免這種情況,除非這是您唯一的選擇。

或者,Git 可以使用憑據助手將用戶名和密碼提供libCURL。 這是關於 Git 的另一個大秘密: Git根本不進行任何身份驗證。 如果你想聲稱自己是 Barack Obama, 3你可以繼續這樣做, Git 會相信你的

它是其他程序進行身份驗證。 Git 依賴於這些其他程序(尤其是 Web 服務器和 ssh 服務器)進行身份驗證; 這決定了您可以在其他機器上讀取和寫入哪些存儲庫。 在您的本地機器上,本地操作系統的權限決定了您可以讀寫哪些存儲庫。

由於 ssh 有自己的相當大且復雜的方法來處理身份驗證(包括 ssh 代理),因此我們在這里根本不會介紹它,但我將談談使用 libCURL 的憑證助手。 Git 總是有兩個簡單的, storecachestore助手只是將用戶名和密碼保存在一個文件中(它不加密,所以考慮避免這種情況,或者至少,小心保護這個文件)。 cache助手不會永久存儲憑據,而只是臨時存儲,因此危險性較小,但它意味着要卡其他助手的前面 另一個助手可能需要密碼,為了避免每次都輸入密碼,您可以將緩存助手放在中間:如果緩存條目已過期,緩存助手將從下一級助手獲取密碼,現在您必須輸入密碼; 但除此之外,它會傳回緩存的條目,以便您這次不必鍵入它。

用於各種操作系統的 Git 附帶了額外的特定於操作系統的幫助程序。 特別是在 OSX 上,有一個使用 OS X Keychain 軟件的git-credential-osxkeychain助手。 (我不使用這個:我使用 ssh。)

有關所有這些的完整說明,請參閱gitcredentials 文檔 某些特定幫助程序何時以及是否適用於您的特定 https 設置取決於太多因素,無法在這里猜測。


1 Git 沒有內置所有的 https 協議; 相反,Git 只是鏈接到 libCURL。 操作系統的 libCURL 依賴於操作系統,因此這有助於 Git 避免過於依賴操作系統。

2當使用 ssh URL 時,Git 也只是運行 ssh。

3如果你真的巴拉克奧巴馬,你為什么要讀這個?


關於git pull

git pull命令做了兩件事:

  1. 首先,它運行——或嘗試運行—— git fetch 這會連接到其他一些系統並獲得新的提交,或者,在您的情況下,連接失敗(然后停止git pull跟蹤)。

  2. 如果在第 1 步中一切順利, git pull現在運行第二個 Git 命令。 您提前選擇是git rebase還是git merge

命令#2旨在以交互方式工作 無論您選擇哪個命令,Git 都會盡力結合您所做的任何工作,在您的存儲庫中進行新的提交,以及在獲取步驟(命令 #1)期間進入的任何新提交。 這可能需要用戶幫助。 如果是,命令 #2 會打印關於需要什么幫助的消息,並以錯誤狀態終止,在您的 Git 存儲庫中留下一團糟。 在您嘗試進一步操作之前,必須清除這些混亂。

因為我們首先不知道命令 #2是否會成功,所以在無人值守的腳本中使用git pull總是一個壞主意。 我們可以猜測命令 #1 是否可能成功,並在腳本中檢查它,所以在腳本中使用git fetch是可以的。 但是,在任何無人值守的腳本中使用git rebasegit merge永遠都不好,除非您的腳本檢查失敗並安排一些有用的事情發生(提醒人類,停止嘗試進一步的命令,等等)。

腳本中正確執行所有這些操作,您必須git pull分解為其組成步驟,因為git pull失敗可能意味着:

  • 獲取失敗:可能是暫時的網絡故障; 沒什么大不了; 請稍后再試!
  • 第二步失敗:災難! 不要繼續。

您需要知道發生了哪些,因此您不能使用git pull

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM