跳到主要內容

發表文章

Robot Framework升級到4.1.2之後,為何Jenkins的Report突然不會報錯了?

最近我們在把Robot升級到3.2.2之後,我想說試試看4.1.2,於是就直接升了上去。沒想到daily build的測試沒發生任何異常。 但不幸的是Jenkins的報表怪怪的: 發生錯誤確Build Success! 趁著颱風假,比較了一下發現新版本的Critical tests測試項目皆為0: 查了一下 官方文件 發現是因為4.0之後,已經把Critical tests概念刪除了,詳細可以參考: Migrating from criticality to SKIP。 解決方法有3種, 自己定義Critical tests,不過看起來5.0就移掉了。 可能可以更新robot framework plugin。我們版本很舊,是1.6.4。因為目前還沒有更新jenkins的計畫,所以我使用了第三個方法。 Build成功與否的Threshold別用Critical tests。 最後測試結果:

解決RobotFramework從3.1.2升級到3.2.2之後,Choose File突然會整個Hand住的問題

考慮到自動測試環境的維護,我們很久以前就使用java去執行robot framework。前陣子開始處理從3.1.2升級到3.2.2的事情,主要先把明確的runtime語法錯誤與deprecate item處理好,這部分內容可以參考: link 。 直到最近才發現,透過SeleniumLibrary執行Choose File去上傳檔案的動作,會導致測試案例timeout。本篇文章主要分享心路歷程與解決方法,我也送了一條issue給robot framework: link 。 我的環境如下: RobotFramework: 3.2.2 Selenium: 3.141.0 SeleniumLibrary: 3.3.1 Remote Selenium Version: selenium-server-standalone-3.141.59 首先並非所有Choose File的動作都會hang住,有些測試案例是可以執行的,但是上傳一個作業系統ISO檔案一定會發生問題。後來我透過wireshark去比對新舊版本的上傳動作,因為我使用 Remote Selenium ,所以Selenium會先把檔案透過REST API發送到Remote Selenium Server上。從下圖我們可以發現,在3.2.2的最後一個TCP封包,比3.1.2大概少了500個bytes。 於是就開始了我trace code之路。包含SeleniumLibrary產生要送給Remote Selenium Server的request內容,還有HTTP Content-Length的計算,我都確認過沒有問題。 最後發現問題是出在socket API的使用上,就是下圖的這支code: 最後發現可能因為開始使用nio的方式送資料,但沒處理到尚未送完的資料內容,而導致發生問題。加一個loop去做計算就可以解決了。 最後我有把解法提供給robot framework官方,在他們出新的版本之前,我是將改完的_socket.py放在我們自己的Lib底下,好讓我們測試可以正常進行。(shutil.py應該也是為了解某個bug而產生的樣子..)

Unexpected reply from ssh-agent: SSH_AGENT_FAILURE

最近在新的開發機上安裝RockyLinux 9.4並且設定git與eclipse。結果要抓code的時候,egit就彈了這個錯誤給我: git@blog.tonylin.idv.tw:tony/commons.git: Unexpected reply from ssh-agent: SSH_AGENT_FAILURE 最後發現有2個解法。方法1,調整ssh key的權限: chmod 600 ~/.ssh/id_rsa chmod 644 ~/.ssh/id_rsa.pub 方法2,到Eclipse Preferences>Git後,別啟用SSH agent:

Intel 13代、14代災難

Intel 13代14代的災情,已經燒好一陣子了,甚至有人提供了測試步驟,讓你可以去測試看你是否為受災戶,詳情可以看以下兩個連結內容: 災情: link 測試: link 不過我腦子沒進水,根本不想去做測試,然後再RMA浪費我自己時間。我大概這個月初就開始等待MSI出新版本來解決我的問題。首先確認一下自己的板子名稱還有BIOS版本,我使用命令提示字元+wmic: wmic baseboard get product,Manufacturer,version,serialnumber wmic bios get BIOSVersion 接著就是上MSI官網下載BIOS,我板子對應連結是: link 。當時我看到8/1版本就有更新CPU的microcode,於是我就更新下去了: 產生了兩個結果: 作業系統啟動金鑰與使用者登入資訊遺失,就是要重新設定。 主機板的音效卡抓不到了。 第二個問題我降回2023年9月的版本就回復了,所以很明顯是BIOS問題,於是我就直接使用提問的功能: 最後MSI給了我一個中繼的測試版,然後再升級到新版本就解決音效卡的問題。但沒想到8/16出的版本才是真正修正這個災情的版本: 請認得0x129,請認得0x129,請認得0x129。 很重要,避免你走冤枉路。

git - 好用的command

列出兩週內有人修改過的branches 這個可以用來review即將要回master的branch有哪些。使用方法: 使用PowerShell切到repository對應目錄執行以下腳本。如果不要兩週,可以把-14改成你要的天數。 $GIT_REPO_LOCATION="D:\workspace\git\Commons\" cd $GIT_REPO_LOCATION git for-each-ref --sort=-committerdate --format="%(refname:short), %(committerdate:iso8601), %(authorname)" refs/remotes/ | ForEach-Object {     $line = $_ -split ', '     $date = [datetime]$line[1]     if ($date -ge (Get-Date).AddDays(-14)) {         Write-Output $_     } } pause 範例輸出: origin/integration_testing, 2024-08-01 18:54:02 +0800, MJGood origin/staging, 2024-08-01 18:54:02 +0800, MJBad origin/supportCup, 2024-08-01 17:15:21 +0800, MJSmall origin/master, 2024-08-01 12:17:08 +0800, MJBig 列出有哪些branch merge到staging 這個主要是用來解決staging重做的問題,再也不需要肉眼去掃branch了。如果你的branch不叫staging,可以自己把下方名字改掉。使用方法: 使用PowerShell切到repository對應目錄執行以下腳本。 $localBranches = git branch --format="%(refname:short)" | Sort-Object $remoteBranches = git branch -r --format="%(refname:short)&quo

Apply DriverDisk on RHEL/CentOS6

Problem 在系統自動安裝部屬時,可能有以下原因需要更新驅動: 安裝光碟搭載的kernel版本不支援新硬體。 安裝光碟搭載的kernel版本過舊。 最常遇到的問題,莫過於在更新網卡或磁碟陣列驅動了。如果使用kickstart自動部屬,在發生硬體找不到時,應會出現如下圖錯誤: 本篇主要分享我解決此問題的方法,有以下幾個步驟: 準備driver rpm。 製作driverdisk。 指定driverdisk。 調整kickstart檔案。 準備driver rpm 準備rpm目前我試了兩種方法: 直接透過rpmbuild打包Intel下載的驅動包。 自行撰寫rpm spec檔案去產生rpm檔。 透過Intel驅動包產生rpm 最初使用這方法產生的rpm包裝driverdisk,卻發現一直無法正常載入: 在使用方法二與檢查driverdisk程式碼後,發現原因主要有二: kernel-modules版本的判別: .spec的Providers宣告不滿足需求,參考程式碼 link 與 link 。 kernel-modules檔案的副檔名: 檔名需為.ko,參考程式碼 link 。 因此針對Intel驅動包內的.sepc,我做了以下修改(以ixgbe驅動為例): # 原本為Provides: %{name},修改為以下 Provides: kernel-modules > = 2.6.32- 220   # 原本為將ixgbe.ko改名為ixgbe.ko.new,我改為複製並放入檔案清單中 find lib -name "ixgbe.*o" -exec cp { } { } .new \; \ -fprintf % { _builddir } /% { name } - % { version } / file.list "/%p.new \n /%p \n " 修改後再重新產生的rpm與driverdisk就能夠正常載入驅動。 自行撰寫rpm spec去產生rpm 一開始使用方法一失敗後,並沒足夠時間追究原因,後來是學網路上教學自己寫。 製作driverdisk 我所產生的driverdisk,以iso為主;driverdisk的內容,會長這樣: rhdd3 rpms / rpms

RHEL/CentOS7在執行kickstart安裝時的DHCP Timeout設定

Problem 本篇主要說明如何在RHEL/CentOS7上設定DHCP Timeout。首先在安裝系統或找某個既有系統,觀察某張抓不到DHCP網卡的log: 以上圖測試結果,並且確認過Anaconda的source code,可以得知預設timeout為45秒。在寫本篇文章之前,已經試過了以下幾種方式且失敗: kickstart中加入–dhcptimeout。 在/etc/dhclient.conf與/etc/dhcp/dhclient.conf加入timeout。 在NetworkManager.conf加入ipv4.dhcp-timeout設定。 也透過nmcli試圖修改ipv4.dhcp-timeout設定,但在CentOS7.2上找不到此設定。 以上方法測試於CentOS7.2中。 How to resolve? 經由尋找解答與測試過程中,得知RHEL/CentOS7的安裝環境,網路是透過NetworkManager控制與設定: 而在網卡還沒正常啟動前,NetworkManager每隔一段時間就會透過dhclient重新偵測此網卡。假如你的DHCP Server有機會能在45秒內完成配置,那就不會有問題;如果不行,那請繼續看下去。經過研究一番,我在RHEL7.3 beta release note中,發現是可以在ifcfg設定檔中,加入IPV4_DHCP_TIMEOUT設定dhcp timeout: DHCP timeout in NetworkManager is configurable The faster fallback in a Dynamic Host Configuration Protocol (DHCP) negotiation is useful in case a server is not present. With this update, the user can set the value of the ipv4.dhcp-timeout property or the IPV4_DHCP_TIMEOUT option in the ifcfg files. As a result, NetworkManager waits for a response from the DHCP server only for a giv