rfc:travis_ci
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
rfc:travis_ci [2014/04/13 09:37] – stas | rfc:travis_ci [2018/03/01 23:48] (current) – RFC was accepted + typo carusogabriel | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== PHP RFC: Keeping | + | ====== PHP RFC: Keeping |
* 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: | + | * Status: |
* First Published at: http:// | * First Published at: http:// | ||
===== Introduction ===== | ===== Introduction ===== | ||
We have a [[https:// | We have a [[https:// | ||
- | 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' | there' | ||
- | never kept in the green for more than a a few days, the " | + | never kept in the green for more than a few days, the " |
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, | + | For the changes committed to multiple branches, the RM of the lowest branch is considered responsible, |
===== Proposed PHP Version(s) ===== | ===== Proposed PHP Version(s) ===== | ||
The policy would apply for all branches in active development or maintenance, | The policy would apply for all branches in active development or maintenance, | ||
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=" |
- | | + | * Yes |
+ | * No | ||
+ | </ | ||
+ | |||
+ | 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=" | ||
+ | * Revert ASAP | ||
+ | * Revert after 1 week | ||
+ | * XFAIL | ||
+ | * Update test | ||
+ | </ | ||
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)