跳到內容

ROSE 編譯器框架/持續整合

Add links
來自華夏公益教科書，為開放世界提供開放書籍
使用 Git 和 Jenkins 的 ROSE 持續整合（為簡單說明省略程式碼審查）

動機

[編輯 | 編輯原始碼]

如果沒有自動化的持續整合，我們經常會遇到以下情況：

  • 開發人員 A 向我們中央 Git 倉庫的 master 分支提交了一些內容。提交包含一些錯誤，導致我們的構建失敗，並且修復需要很長時間。然後中央 master 分支會處於損壞狀態數週，因此沒有人可以簽出/簽入任何內容。
  • 開發人員 A 離線做了很多很棒的工作，持續了幾個月。但後來發現她的工作與另一個開發人員的工作不相容。她的工作存在無法解決的合併衝突。

概述

[編輯 | 編輯原始碼]

ROSE 專案使用了一個工作流程，該工作流程自動執行了 持續整合 的核心原則，以便將不同開發人員的工作整合在一起變得毫不費力。由於整合過程只將透過所有測試的更改整合到 ROSE 中，因此我們鼓勵所有開發人員與最新版本保持同步。

ROSE 開發人員使用的開發模型的概述。

  • 步驟 1：利用基於 Git 的分散式原始碼倉庫，每個開發人員應該首先從我們的中央 Git 倉庫（或其映象/克隆/分支）克隆自己的倉庫。
  • 步驟 2：然後，可以在私有倉庫中獨立地開發功能或修復錯誤。開發人員可以建立任意數量的私有分支。每個分支都應該與該開發人員正在處理的功能相關聯，並且應該是相對短命的。開發人員可以將更改提交到私有倉庫，而無需與共享倉庫保持活躍的連線。
  • 步驟 3：當工作完成並經過本地測試（make、make check 和 make distcheck -j#n）後，她可以拉取來自中央倉庫 master 分支的最新提交。
  • 步驟 4：然後，她可以將私有倉庫中積累的所有提交推送到共享倉庫中的分支。我們為每個開發人員在中央倉庫中建立一個專用分支，並建立分支的訪問控制，以便只有授權的開發人員才能將提交推送到共享倉庫的特定分支。
  • 步驟 5-6（自動）：來自開發人員私有倉庫的任何提交都不會立即合併到共享倉庫的 master 分支。

事實上，我們有訪問控制來阻止任何開發人員將提交推送到共享倉庫的 master 分支。一個名為 Jenkins 的持續整合伺服器正在積極監視中央倉庫中每個開發人員的分支，並在檢測到新的提交後，將對該分支啟動全面的提交測試。最後，如果所有測試透過，Jenkins 將新的提交合併到中央倉庫的 master 分支。如果單個測試失敗，Jenkins 將報告錯誤，負責的開發人員應該在他們的私有倉庫中解決錯誤，然後再次推送改進的提交。

因此，中央 Git 倉庫的 master 分支基本上是穩定的，可以成為我們外部發布的良好候選者。在中央 Git 倉庫的 master 分支之上，我們在 Jenkins 中進一步進行更全面的釋出測試。如果所有釋出測試透過，將基於 master 分支的外部版本在外部發布。

Jenkins 上的測試

[編輯 | 編輯原始碼]

我們使用 Jenkins（http://hudson-rose-30:8080/）來測試新增到中央 Git 倉庫的開發人員釋出候選分支的提交。

測試分為三類：

  • 整合：用於檢查新的提交是否能透過各種 "make check" 規則、相容性測試、可移植性測試、配置測試等。如果所有測試透過，提交將被合併（或整合）到中央倉庫的 master 分支。
  • 釋出：使用外部基準對更新後的中央倉庫 master 分支進行額外的一組測試。如果所有測試透過，master 的頭部將被釋出為一個穩定的快照，用於公共檔案包釋出（由 "make dist" 生成）。
  • 其他：目前用於資訊目的，沒有在我們的生產工作流程中使用。

因此，對於每個推送（一個或多個提交到 -rc 分支），它將經過兩個階段：整合測試階段和釋出測試階段。

每個開發人員有責任確保他們的提交能透過兩個階段的測試，方法是透過修復測試發現的任何錯誤。

安裝的軟體包

[編輯 | 編輯原始碼]

這裡列出了 Jenkins 安裝和使用的軟體包。

  • Yices: /export/tmp.hudson-rose/opt/yices/1.0.34

開發 Jenkins

[編輯 | 編輯原始碼]

幾個配置

GCC_VERSION=4.4.7
BOOST_VERSION=1_47_0
source /nfs/casc/overture/ROSE/opt/rhel6/x86_64/rose_environment.sh
__rose__JAVA_VERSION_HOME=/nfs/casc/overture/ROSE/opt/rhel6/x86_64/java/jdk/1.7.0_51

GCC_VERSION=4.8.1
BOOST_VERSION=1_50_0
source /nfs/casc/overture/ROSE/opt/rhel6/x86_64/rose_environment.sh
__rose__JAVA_VERSION_HOME=/nfs/casc/overture/ROSE/opt/rhel6/x86_64/java/jdk/1.7.0_51

檢查測試結果

[編輯 | 編輯原始碼]

可以手動跟蹤您的提交在 Jenkins 測試管道中的進度（http://hudson-rose-30:8080/）。但這樣做可能會很乏味和難以管理。

因此，我們提供了一個儀表板（http://sealavender:4000/）來總結對您的釋出候選分支 (-rc) 的提交以及每個整合測試的透過/失敗狀態。

注意：所有測試作業（最終）都可能透過，但實際的整合未執行。這通常發生在您的作業之一齣現系統故障時，例如，因此需要手動重新啟動。如果您發現所有作業都已透過，但您的工作尚未整合，請聯絡 Jenkins 管理員。

經常失敗的任務

[編輯 | 編輯原始碼]

在 ROSE 編譯器框架/Jenkins 失敗 中檢視詳細資訊。

與程式碼審查的連線

[編輯 | 編輯原始碼]
Github Enterprise 和 Jenkins 之間的連線

實際上，現在大多數 LLNL 開發人員被要求首先將內容推送到 Github Enterprise 進行 程式碼審查，而不是直接推送到我們的中央 Git 倉庫。Github Enterprise 的程式碼審查倉庫和我們的中央 Git 倉庫之間的同步是自動化的。

自動拉取

[編輯 | 編輯原始碼]

自動拉取：我們在 (https://hudson-rose-30:8443/jenkins/) 還有一個 Jenkins 伺服器，它充當 Github 企業版和我們主要生產 Jenkins 之間的橋樑。

  • 對於 Github 企業版上的每個私有倉庫，我們都有一個 Jenkins 任務來監控 master 分支以獲取已批准的拉取（合併）請求。如果有任何新的已批准的提交，該任務將把提交轉移到該開發人員的中央倉庫的 -reviewed-rc 分支。

自動拉取任務的配置

  • 原始碼管理
    • git: git@github.llnl.gov:account_name/rose.git
    • 要構建的分支：github/master
  • 構建觸發器：輪詢 SCM，計劃 "* * * * *"
  • 執行 shell
##
## Add /nfs as remote
##
## `|| true`: don't error if remote exists
##
git remote add nfs /nfs/casc/overture/ROSE/git/ROSE.git || true
git fetch nfs

##
## Push to /nfs *-rc
##
if [ -n "$(git log --oneline nfs/master..github/master)" ]; then
  git push --force nfs "$GIT_BRANCH":refs/heads/oun-reviewed-rc
fi

自動推送

[編輯 | 編輯原始碼]

自動推送：一個 Jenkins 任務負責將最新的中央 master 內容傳播到 github.llnl.gov 上的所有私有倉庫。

該任務的配置

  • 原始碼管理
    • Git: /nfs/casc/overture/ROSE/git/ROSE.git
    • 要構建的分支：*/master
  • 構建觸發器：在其他專案構建後構建：提交
  • 執行 Shell
USERS="\
user1\
user2
"

for user in $USERS; do
  tmpfile="$(mktemp)"
  ( git push git@github.llnl.gov:"$user"/rose.git origin/master:refs/heads/master 2>"$tmpfile" ) || true
  set +e
  cat "$tmpfile"
  cat "$tmpfile" | grep -q "non-fast.*forward"
  if [ $? -eq 0 ]; then
    echo "Sending error email to [${user}@llnl.gov] because their github/master is non-fast-forwardable"
    # email details are omitted here.
  fi
done

重現 Jenkins 任務故障

[編輯 | 編輯原始碼]

幾個關鍵要素

  • Jenkins 指令碼庫
  • 正確的 ROSE 版本
  • 硬體機器
  • 環境

假設一個失敗的任務是 https://hudson-rose-44.llnl.gov:9443/jenkins/job/development-compile-with-autotools-default-EDG-RHEL6/892/gcc=4.4.7,label=RHEL6,rhel=6/parameters/

步驟

#!/bin/bash -ex

export GCC_VERSION="$gcc"

rm -rf ./jenkins-build-scripts/ || exit 1
git clone rose-dev@rosecompiler1.llnl.gov:jenkins/dev/jenkins-build-scripts.git || exit 1
source ./jenkins-build-scripts/config/env-Linux.sh $gcc $rhel || exit 1
./jenkins-build-scripts/development/development-compile-with-autotools-default-EDG-RHEL6.sh $gcc || exit 1
  • 相同的配置頁面包含一個配置矩陣，其中包含所有使用者定義的引數和值，包括 gcc 版本、作業系統版本和其他引數。

現在手動簽出提交，並使用傳遞的正確 gcc 版本和 rhel 版本執行指令碼

  • ../jenkins-build-scripts/config/env-Linux.sh "4.4.7" 6
  • git clone rose-dev@rosecompiler1.llnl.gov:rose/scratch/rose sourcetree
  • cd sourcetree/
  • git checkout -b autopar 83abd459eee1b575b4e7fab04a9f1dfc4955f02a
  • git submodule init
  • git submodule update
  • ../jenkins-build-scripts/development/development-compile-with-autotools-default-EDG-RHEL6.sh 4.4.7

待辦事項

[編輯 | 編輯原始碼]

高優先順序

  • 在手動程式碼審查開始之前新增一個預篩選任務。預篩選任務可以確保要審查的程式碼將使用最少的警告訊息進行編譯，並且具有執行測試所需的 make check 規則。
  • 為每個測試的最終結果啟用電子郵件通知
  • 逐步新增更多使用外部基準的編譯測試，作為整合測試。
    • 最初的兩個任務：spec cpu 基準 + NPB Fortran 基準
  • 更好地與 Github 企業版整合

在 Jenkins 中安裝用於測試的第三方軟體。

  • Yices (http://yices.csl.sri.com/)
    • 下載 Yices1，最新版本更好。
    • 解壓縮 yices 的 tarball 包，然後是 YICES_INSTALL，類似於 yices-1.0.34
    • 使用 ROSE/configure 選項輸入 --with-yices=YICES_INSTALL
    • 將 YICES_INSTALL/lib 設定為 Linux 的 LD_LIBRARY_PATH 和 mac 使用者的 DYLD_LIBRARY_PATH，這類似於將 Boost/lib 新增到 LD_LIBRARY_PATH

參考

[編輯 | 編輯原始碼]
  • 用於生成圖形的檔案：隨時新增新版本的幻燈片：連結
檢索自 "https://wikibook.tw/w/index.php?title=ROSE_Compiler_Framework/Continuous_Integration&oldid=3460198"
華夏公益教科書