幫助測試PR¶

作為一名開發者，最具能展現自我價值的事情就是在github上看討論列表來幫助修復bug。我們通常在解決了bug之後再進行新功能的開發，因此解決bug將是一個非常有價值的事情。

即使你不是一個開發者，幫助測試bug的修復情況以及新功能還是非常有必要的。

這同樣適用於測試新功能以及測試錯誤修正。

通常情況下，編碼工作應當包含測試用例來保證編碼的正確性，但這並不總能照顧到程式碼的方方面面，尤其在各平臺下測試使用者沒有足夠的訪問許可權，或者使用的是API或者web服務。

在這種情況下，在真實的環境下上線測試將會比自動測試更有價值。在任何情況下，都是應該進行一次人工測試。

幸運的是在你充分了解ansible的工作機制的情況下，幫助測試ansible是一件非常簡單的事情。

開始測試¶

你可以在ansible主分支上切出一個分支來保持和主分支隔離，合併GitHub上的問題，測試，然後在GitHub對這一特定問題做一個回饋。具體方法如下：

Note

幫助測試GitHub上那些提交合並請求的程式碼是否存在風險，這些風險可能包括存在錯誤或惡意程式碼。我們建議在虛擬機器上測試，無論是雲，或在本地。有些人喜歡Vagrant，或Docker，這是可以的，但我們並不推薦。在不同的Linux系統環境下進行測試也是非常有意義的，因為某些功能（諸如APT和yum等包管理工具）專用於這些作業系統。

當然配置您的測試環境來執行我們的測試套件需要一系列工具。以下軟體是必須的:

git
python-nosetests (sometimes named python-nose)
python-passlib
python-mock

如果你想執行完整的整合測試套件，你還需要安裝以下軟體包:

svn
hg
python-pip
gem

當準備完以上環境後，您可以從github上拉取Ansible的原程式碼進行測試了:

git clone https://github.com/ansible/ansible.git --recursive
cd ansible/

Note

如果您已經Fork了我們的程式碼，您就可以從你自己程式碼倉庫裡克隆了。

Note

如果你打算更新你的倉庫作為測試一些相關模組，請使用”git rebase origin/devel”，並且使用”git submodule update”更新子模組，如不更新，您將使用舊版本的模組。

使用開發環境¶

Ansible原始碼包括一個指令碼，可以讓你直接使用Ansible從原始碼，而無需完全安裝，這對於的Ansible開發者來說十分便利。

使用以下命令進入開發環境，這主要針對的是Linux/Unix的終端測試環境:

source ./hacking/env-setup

該指令碼修改了PYTHONPATH（以及一些其他的東西），這僅僅對於當次shell 會話有效。

如果你想永久使測試環境生效，你可以將其放入開機啟動指令碼中（例如，.bash_profile）。

找到對應分支並測試¶

接下來，手動合併你想測試的提交請求，並且記錄下源和倉庫的資訊。它會是這個樣子:

Someuser wants to merge 1 commit into ansible:devel from someuser:feature_branch_name

Note

請務必將提交合並請求提交到ansible:devel分支，我們不會接受您提交到其他分支。版本的更新將由我們的工作人員手動進行。

使用者名稱和分支名是十分重要的，這將顯示在以下命令列中:

git checkout -b testing_PRXXXX devel
git pull https://github.com/someuser/ansible.git feature_branch_name

第一行命令表示在devel分支上新建一個新分支名叫testing_PRXXXX，而XXXX是實際合併請求申請的ID號（例如，1234），並切換到該分支下。第二行命令則表示拉取對應使用者的對應分支的程式碼。

Note

If the GitHub user interface shows that the pull request will not merge cleanly, we do not recommend proceeding if you are not somewhat familiar with git and coding, as you will have to resolve a merge conflict. This is the responsibility of the original pull request contributor.

Note

Some users do not create feature branches, which can cause problems when they have multiple, un-related commits in their version of devel. If the source looks like someuser:devel, make sure there is only one commit listed on the pull request.

For Those About To Test, We Salute You¶

At this point, you should be ready to begin testing!

If the PR is a bug-fix pull request, the first things to do are to run the suite of unit and integration tests, to ensure the pull request does not break current functionality:

# Unit Tests
make tests

# Integration Tests
cd test/integration
make

Note

Ansible does provide integration tests for cloud-based modules as well, however we do not recommend using them for some users due to the associated costs from the cloud providers. As such, typically it’s better to run specific parts of the integration battery and skip these tests.

Integration tests aren’t the end all beat all - in many cases what is fixed might not HAVE a test, so determining if it works means checking the functionality of the system and making sure it does what it said it would do.

Pull requests for bug-fixes should reference the bug issue number they are fixing.

We encourage users to provide playbook examples for bugs that show how to reproduce the error, and these playbooks should be used to verify the bugfix does resolve the issue if available. You may wish to also do your own review to poke the corners of the change.

Since some reproducers can be quite involved, you might wish to create a testing directory with the issue # as a sub- directory to keep things organized:

mkdir -p testing/XXXX # where XXXX is again the issue # for the original issue or PR
cd testing/XXXX
<create files or git clone example playbook repo>

While it should go without saying, be sure to read any playbooks before you run them. VMs help with running untrusted content greatly, though a playbook could still do something to your computing resources that you’d rather not like.

Once the files are in place, you can run the provided playbook (if there is one) to test the functionality:

ansible-playbook -vvv playbook_name.yml

If there’s not a playbook, you may have to copy and paste playbook snippets or run a ad-hoc command that was pasted in.

Our issue template also included sections for “Expected Output” and “Actual Output”, which should be used to gauge the output from the provided examples.

If the pull request resolves the issue, please leave a comment on the pull request, showing the following information:

“Works for me!”

The output from ansible –version.

In some cases, you may wish to share playbook output from the test run as well.

Example!:

Works for me!  Tested on `Ansible 1.7.1`.  I verified this on CentOS 6.5 and also Ubuntu 14.04.

If the PR does not resolve the issue, or if you see any failures from the unit/integration tests, just include that output instead:

This doesn't work for me.

When I ran this my toaster started making loud noises!

Output from the toaster looked like this:

   ```
   BLARG
   StrackTrace
   RRRARRGGG
   ```

When you are done testing a feature branch, you can remove it with the following command:

git branch -D someuser-feature_branch_name

We understand some users may be inexperienced with git, or other aspects of the above procedure, so feel free to stop by ansible-devel list for questions and we’d be happy to help answer them.