rfc:travis_ci

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
rfc:travis_ci [2014/04/13 09:37] stasrfc:travis_ci [2018/03/01 23:48] (current) – RFC was accepted + typo carusogabriel
Line 1: Line 1:
-====== PHP RFC: Keeping Unit Tests Green ======+====== PHP RFC: Keeping PHPT Tests Green ======
   * Version: 1.0   * Version: 1.0
   * Date: 2014-04-13   * Date: 2014-04-13
   * Author: Stas Malyshev (stas@php.net)   * Author: Stas Malyshev (stas@php.net)
-  * Status: Draft+  * Status: Accepted
   * First Published at: http://wiki.php.net/rfc/travis_ci   * First Published at: http://wiki.php.net/rfc/travis_ci
  
 ===== Introduction ===== ===== Introduction =====
 We have a [[https://travis-ci.org/php/php-src/|setup on Travis CI]] which automatically We have a [[https://travis-ci.org/php/php-src/|setup on Travis CI]] which automatically
-runs unit tests for our active branches. This is very convenient for+runs PHPT tests for our active branches. This is very convenient for
 evaluating pull request and status of the branches and keeping us from evaluating pull request and status of the branches and keeping us from
 making changes that break something without us noticing. However, making changes that break something without us noticing. However,
 there's a problem with this setup, and the problem is that CI build is there's a problem with this setup, and the problem is that CI build is
-never kept in the green for more than a few days, the "normal" state+never kept in the green for more than a few days, the "normal" state
 of it is always failing. I think this situation is not normal and embarrassing for the project, and propose to institute a policy of it is always failing. I think this situation is not normal and embarrassing for the project, and propose to institute a policy
 to change it. to change it.
Line 30: Line 30:
 It is proposed that the main responsibility of keeping the CI tests green will rest with the RM of the particular branch, in case of version branch. One of the responsibilities is that the release should not be made unless the CI tests are green, and the RM is primarily responsible for bringing it to green in one of the ways described below.  It is proposed that the main responsibility of keeping the CI tests green will rest with the RM of the particular branch, in case of version branch. One of the responsibilities is that the release should not be made unless the CI tests are green, and the RM is primarily responsible for bringing it to green in one of the ways described below. 
  
 +We will also add instructions for the RM to README.RELEASE_NOTES on how to verify the release branch and ensure everything passes. 
 === Fixing tests === === Fixing tests ===
  
Line 45: Line 46:
 These policies would also apply to any future CI system we may introduce, such as [[Jenkins]]. These policies would also apply to any future CI system we may introduce, such as [[Jenkins]].
  
-For the changes committed to multiple branches, the RM of the lowest branch is considered responsible, but if he is unable to resolve the problem, the RMs for other branches can step in. +For the changes committed to multiple branches, the RM of the lowest branch is considered responsible, but if they are unable to resolve the problem, the RMs for other branches can step in. 
 ===== Proposed PHP Version(s) ===== ===== Proposed PHP Version(s) =====
 The policy would apply for all branches in active development or maintenance, starting with PHP 5.5.  The policy would apply for all branches in active development or maintenance, starting with PHP 5.5. 
Line 53: Line 54:
 Proposed votes are as follows: Proposed votes are as follows:
  
-  - Accept the description in this RFC as an official policy of the PHP project with regard to unit tests. +<doodle title="Accept the description in this RFC as an official policy of the PHP project with regard to the tests" auth="user" voteType="single" closed="true"> 
-  Choose one or more of the four options above of handling bad commits, keeping in mind that choosing particular option would be the decision of the RM. +   * Yes 
 +   * No 
 +</doodle> 
 + 
 +Choose one or more of the four options above of handling bad commits, keeping in mind that choosing particular option would be the decision of the RM.  
 + 
 +<doodle title="Choose one or more of the four options above of handling bad commits" auth="user" voteType="multi" closed="true"> 
 +   * Revert ASAP 
 +   * Revert after 1 week 
 +   * XFAIL 
 +   * Update test 
 +</doodle>
  
 The RFC will be considered accepted if over 50% vote for the acceptance, and any option having the vote of more than 50% of the voters will be considered approved. If none of the options get 50% acceptance but the first item will, the exact handling of the bad commits will be considered to be defined and in the meantime be the decision of the RMs.  The RFC will be considered accepted if over 50% vote for the acceptance, and any option having the vote of more than 50% of the voters will be considered approved. If none of the options get 50% acceptance but the first item will, the exact handling of the bad commits will be considered to be defined and in the meantime be the decision of the RMs. 
 +
 +Voting period: April 26 - May 5
  
 ===== References ===== ===== References =====
rfc/travis_ci.1397381846.txt.gz · Last modified: 2017/09/22 13:28 (external edit)