PRolice
v0.0.1 -
ooooooooo. ooooooooo. oooo o8o
`888 `Y88. `888 `Y88. `888 `"'
888 .d88' 888 .d88' .ooooo. 888 oooo .ooooo. .ooooo.
888ooo88P' 888ooo88P' d88' `88b 888 `888 d88' `"Y8 d88' `88b
888 888`88b. 888 888 888 888 888 888ooo888
888 888 `88b. 888 888 888 888 888 .o8 888 .o
o888o o888o o888o `Y8bod8P' o888o o888o `Y8bod8P' `Y8bod8P'
------------ What you gonna do when they come for you -------------
ProLice （ PR警察的收縮）是一種工程管理工具，用於取消和測量GitHub存儲庫中的請求數據。
向Sourcelevel及其關於指標的出色博客大喊（其大多數由此應用程序實施）：
作為開發工作流程的一部分，許多工程經理促進拉力請求。這是一種合併的做法，帶來了很多好處。它包括將分支的更改與存儲庫的基本分支（常規稱為主）進行比較。
拉請求提供有用且可操作的指標。但是，遵循錯誤的指標會導致扭曲，並帶來比利益更多的缺點。經理可以使用拉動請求指標來理解團隊動態，並在事情脫離軌道之前適當地採取行動以糾正行為。
Prolice旨在從目標存儲庫中收集拉動請求樣本並分析它們，以便洞悉集體項目的工作流程。
再次大喊到Sourcelevel的博客文章（認真地，如果您還沒有，請閱讀）：
在進入指標之前，我想發出免責聲明：不要使用這些數字來比較個人。
有時，一個難以找到的錯誤需要修復單行代碼，而單線需要一周的工作。在我的職業生涯中，我已經見證了很多次。
我還目睹了工程經理，鼓勵開發人員開放提取請求，並進行太多的更改，以至於審查是不可行的。他們通常會強調，通過告訴每個人，這些開發人員都有生產力，當其他人拿最簡單的開發人員時，他們正在做艱苦的工作。
通過拉動請求衡量個人甚至可能不公平。致力於維護舊版代碼庫的開發人員往往比另一個適用於Greenfield項目的開發人員要慢。
這就是為什麼測量拉力請求很棘手的原因。工程經理不能將拉力請求數據用於評估個人。如果您確實提取請求，則希望您的團隊合作。在這種實踐中，協作是核心價值。開發人員的努力不能僅僅通過打開或合併多少個拉力請求來衡量。甚至最糟糕的是，努力並不代表其大小。
首先，您將必須創建個人訪問令牌。這是一次性的要求，不應花費幾分鐘。
代幣將需要閱讀對存儲庫的訪問並提取請求，以便進行Prolice工作。這樣的事情：
有了您的個人訪問令牌，並從發行版的部分下載了二進製文件後，請在您最喜歡的首選終端中調用Prolice -Linux和MacOS（Darwin）得到了支持：
prolice --owner < owner > --repository < repository > --github-token < github-token >例如，如果我們想衡量Rust的官方存儲庫指標（注意：默認為100個PRS的樣本）：
prolice --owner rust-lang --repository rust --github-token < github-token >個人公關指標也得到了支持：
prolice --owner rust-lang --repository rust --pr-number 32000 --github-token < github-token > Prolice的S有幾個標誌和可選參數，可用於調整其冗長和样本大小：
prolice --helpUSAGE:
prolice [FLAGS] [OPTIONS] --owner < owner > --repository < repository > --sample-size < sample-size > --github-token < github-token >
FLAGS:
-h, --help Prints help information
-m, --include-merge-prs Marks merge-PRs as valid targets for analysis (by default these are
excluded). Valid only for whole Repository analysis ; for individual
PR analysis this flag is ignored
-l, --print-legends Prints the metrics ' legends before sending the operation results to
stdout.
-s, --silent-mode Marks the operation as silent, which turns off all logging and
printing to stdout, with the sole exception of the analysis results.
This makes it useful for piping just the results, without the added
' noise ' . (NOTE: piping is automatically detected, which activates
silent-mode without having to explicitly add the flag to the command)
-V, --version Prints version information
OPTIONS:
-G, --github-token <github-token>
Sets the personal access token under which to perform the PR analysis
-L, --log-level <log-level>
Overrides the logging verbosity for the whole application [default: INFO] [possible
values: INFO, DEBUG, TRACE, WARN, ERROR, OFF]
-O, --owner <owner> The owner of the repository under scrutiny
-P, --pr-number <pr-number>
A specific pull-request to be selected as target for the analysis.
-R, --repository <repository> The repository under scrutiny
-S, --sample-size <sample-size>
The amount of PRs that will be fetched as sample for the analysis (unless a specific PR
number is selected as individual target) [default: 100]ProLice的結果可以將其管道輸送到文件。應用程序會自動檢測到管道（或任何缺乏TTY），即使用戶不提供這些標誌作為命令的一部分，也會關閉所有日誌和消息。這對於獲取可能被饋入另一個過程的原始結果很有用。
例如：
prolice --owner rust-lang --repository rust --github-token < github-token > >> results.json將產生一個results.json文件帶有以下內容（在編寫此讀數時）：
{
"score" : [
{
"AmountOfParticipants" : 4
},
{
"AmountOfReviewers" : 1
},
{
"Attachments" : 1
},
{
"AuthorCommentaryToChangesRatio" : 31.138690476190472
},
{
"PullRequestsDiscussionSize" : 4065
},
{
"PullRequestFlowRatio" : 1.9121686296350902
},
{
"PullRequestLeadTime" : 1
},
{
"PullRequestSize" : 255
},
{
"TestToCodeRatio" : 0.42988095238095236
},
{
"TimeToMerge" : 4
}
]
}每個度量的“含義”（又稱為何要測量的價值）可以通過傳遞--print-legends標誌來打印為分析結果的一部分。儘管如此，這可能會以過多的冗長污染終端。因此，作為參考，這些都是度量標準的含義：
AmountOfParticipants參與公關討論的非作戰人數的數量。更大的參與可能會豐富討論並產生更高質量的代碼。
AmountOfReviewers通過批准或要求進行更改，對公關結果取得立場的非授權人數的數量。這衡量了有效決定公關命運的參與者的數量。
Attachments附件可以是從添加的屏幕截圖到嵌入式PDF文件的任何內容。對於那些具有與之相關的視覺組件的PR特別有用。
AuthorCommentaryToChangesRatio良好的代碼應該是不言自明的；但是，良好的公關還可能包括有關其目標實現的目標，如何做到以及/或為何以選擇的方式進行的額外評論。
纖細的評論可能會使PR模棱兩可，將理解負擔轉移到審稿人身上，並從中消耗額外的時間。另一方面，太多的評論可能會污染不需要的噪音的PR，並產生同樣的效果。
PullRequestsDiscussionSize與作者評論與變化比率類似，它衡量了公關中評論的總數，但無論其來自誰。與社交媒體帖子相反，參與拉動請求過多會導致效率低下。測量每個拉的請求的評論和反應數量，可以使團隊如何合作。協作很棒，它的認可是必需的。但是，經過一定層次，討論放慢了發展。
變得太大的討論可能表明了錯誤的事情：也許團隊不一致，或者軟件要求還不夠精確。無論如何，討論中的錯位不是協作。他們是浪費時間。在相反的情況下，幾乎零參與度意味著代碼審查不是團隊習慣的一部分。
總而言之，該指標必鬚根據團隊的規模和分配達到“理想數字”。它不能太多，也不能太少。
PullRequestFlowRatio拉的請求流量比是一天中開放的拉請請求的總和除以當天的封閉請求之和。該指標顯示了團隊是否在健康的比例中工作。合併拉的請求並部署到生產是一件好事，因為它為最終用戶增加了價值。但是，當團隊關閉拉動請求比打開的更多時，很快就會拉動請求隊列飢餓，這意味著交貨中可能會有中斷。理想情況下，最好確保團隊合併以與他們打開的比例達到比例。接近1：1，越好。
PullRequestLeadTime銷售時間指標想到要合併或關閉的拉動請求多少次（通常是在幾天內）。要查找此數字，打開時每個拉的請求的日期和時間需要合併。公式很容易：對於日期差的簡單平均值。在組織中的所有存儲庫中計算此指標可以使團隊對其動態有更清晰的了解。
PullRequestSize每個公關的大量變化對審稿人施加了壓力，審稿人的注意力對細節的關注減少了變更越大的變化。具有諷刺意味的是，開發人員往往比較短的請求更快地合併拉更長的請求，因為在發生太多事情時，進行徹底的評論更加困難。無論評論的透徹程度如何，大公關都會使時間合併上升，質量下降。
TestToCodeRatio根據經驗，至少應盡可能將PR的一半由測試組成。
TimeToMerge通常，拉動請求正在開放，其中一些正在進行的工作，這意味著測量拉的提示時間並不能說明整個故事。合併的時間是分支機構到達目標分支的第一個提交花費的時間。在實踐中，數學很簡單：這是分支最古老的提交的時間戳，減去合併訂單的時間戳。
與拉的請求提示時間相比，合併的時間通常很有用。以以下示例：
- 拉請提示時間= 3天
- 合併的時間= 15天
在上述情況下，拉動請求平均需要3天的時間合併（這非常好）；但是合併的時間是15天。這意味著開發人員在打開拉動請求之前平均工作12天（15 - 3）。
注意：如果開發人員在將所有更改壓入單個提交中，該指標在將後來用作PR的基礎之前就在WIP分支上工作有些過時（這將使時間有效合併等於拉的請求提前時間）。但是，該指標對於合併PRS仍然非常有用（例如，合併成長）：說PRS將有一個很短的拉力請求提前時間（它們不會得到徹底的重新評估），但是對第一個提交日期（合併的時間）進行測量將使功能要多長時間，以使功能積累到一個有足夠的里程碑中，有足夠的Morestone Morestone Morestone Moresto，成為“大型分支機構”。
cargo編譯刺激物Prolice用生鏽寫。在主機平台中彙編用於使用的應用程序與使用普通的cargo build一樣容易：
cargo build --releasecargo-make （Linux至MacOS）進行交叉編譯刺激讓我們首先從這個很棒的博客文章中的一些序言開始本節：
我討厭十字架編譯
有數百萬的方法可以破壞您正在進行的操作系統，而交叉編譯就是其中之一。通常，它從無辜的想法開始，即您需要一個構建鏈，您需要一個小程序才能在Linksys WRT 1900 ACS上運行（OpenWRT和ARMV7）。
挖掘您在Reddit上找到幾個不同的片段或GitHub項目中的某些問題，其中一個隨機的人發布了幾行Bash，就像您需要的那些丟失的信息一樣。
然後，運行bash可能會導致以下內容之一：
- 創建一個工作的構建鏈（非常不可能）
- 創建一個構建鏈，該鏈將在80％的構建後失敗
- 添加當地的比特幣礦工，同時假裝實際創建一個工作構建鏈
在個人層面上感覺到這些痛苦後，該項目的貨物貨運cargo-makefile.toml中定義的目標在相對無痛的水平上提供了交叉補償。
當然，如果僅為主機機器編譯，則堅持使用純老cargo build始終是首選。但是，假設目標是從頭開始從Linux到MacOS（Darwin），除了正常的銹工具鏈外，您還需要安裝cargo-make ：
cargo install --force cargo-make之後，通過調用彙編步驟完全照顧您：
cargo make --makefile cargo-makefile.toml release-darwin這將創建和放置，在過程完成後，壓縮的二進製文件AT：
<your_dir>/target/release/out/prolice_x86_64-apple-darwin.zip
但是，考慮到跨編譯Linux-to-Darwin需要Docker，因此，您可以再次通過調用普通的舊cargo build來為您的主機機器構建二進製文件，從而再次節省幾個MB。
