WordPress.org

Make WordPress Core

Changes between Initial Version and Version 1 of Ticket #34694


Ignore:
Timestamp:
11/16/2015 04:56:38 AM (5 years ago)
Author:
westonruter
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #34694 – Description

    initial v1  
    77When Travis CI does a build in the context of a pull request, it makes available the branch checked out and the branch being merged into, and with these two refs in hand, we can gather a list of the files (and patches) that were specifically changed. When we have these, we can optimize Travis CI to only run the checks that are relevant to the changes in the feature branch. For instance, if no PHP files were changed, then all of the jobs that run PHPUnit tests can be cancelled. If no JS files were modified, then the JSHint checks can be skipped.
    88
    9 It can be painful to introduce new automated checks to WordPress because they can add a lot of noise for automated tests and fixing requires a touching a lot of files, possibly invalidating many pending patches. When Travis runs in the context of a pull request (or when automated tests are run when `trunk`/`master` is not checked out), then again, there is a diff available for the specific changes. We can introduce PHP_CodeSniffer for core (#30153) when Travis runs in in the context of a pull request, and it can skip reporting errors on any lines that aren't modified in the commit. This is likewise how JSCS linting can be added (#31823).
     9It can be [https://make.wordpress.org/core/2013/11/13/finding-fixing-javascript-errors-with-jshint/ painful] to introduce new automated checks to WordPress because they can add a lot of noise for automated tests and fixing requires a touching a lot of files, possibly invalidating many pending patches. When Travis runs in the context of a pull request (or when automated tests are run when `trunk`/`master` is not checked out), then again, there is a diff available for the specific changes. We can introduce PHP_CodeSniffer for core (#30153) when Travis runs in in the context of a pull request, and it can skip reporting errors on any lines that aren't modified in the commit. This is likewise how JSCS linting can be added (#31823).
    1010
    1111For existing code which causes Travis CI to only report coding standard violations to lines changed, see https://github.com/xwp/wp-dev-lib/blob/master/travis.script.sh when `$LIMIT_TRAVIS_PR_CHECK_SCOPE` is `patches`.