WordPress.org
Get WordPress

Make WordPress Core

Changes between Version 1 and Version 15 of Ticket #34694


Ignore:
Timestamp:
05/16/2017 01:36:28 PM (8 years ago)
Author:
westonruter
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #34694

    • Property Owner set to westonruter
    • Property Status changed from new to accepted
    • Property Milestone changed from Future Release to WordPress.org

  • Ticket #34694 – Description

    v1 v15  
    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 [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).
     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 ESLint can be added (#31823).
    1010
    11 For 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`.
     11For 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/check-diff.sh when `$CHECK_SCOPE ` is `patches`.
    1212
    1313For commits pushed to `master` on Travis CI (outside the context of a pull request), it may make sense to configure Travis to check for changes made since the last major release.