Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upIntroduce automated Travis CI build testing into 2016. #23
Conversation
| # aliased to a recent 5.3.x version | ||
| - "5.3" | ||
| # Current $required_php_version for WordPress: 5.2.4 | ||
| - "5.2" |
aaronjorbin
Aug 29, 2015
Member
5.6 and 7 should also be tested.
5.6 and 7 should also be tested.
| # WordPress 4.3 | ||
| # @link https://github.com/WordPress/WordPress/tree/4.3-branch | ||
| - WP_VERSION=4.3 WP_MULTISITE=0 | ||
| - WP_VERSION=4.3 WP_MULTISITE=1 |
aaronjorbin
Aug 29, 2015
Member
I don't see a reason to test old versions of WordPress. The default theme should have a minimum version of the version it is released on
I don't see a reason to test old versions of WordPress. The default theme should have a minimum version of the version it is released on
philiparthurmoore
Aug 30, 2015
Author
Contributor
The default theme should have a minimum version of the version it is released on
Minimum required version for Twenty Sixteen is 4.2.
I doubt this testing matrix even matters since all we're doing is running the theme through Coding Standards, right now at least. Happy to make any adjustments after discussion during this week's meeting.
The default theme should have a minimum version of the version it is released on
Minimum required version for Twenty Sixteen is 4.2.
I doubt this testing matrix even matters since all we're doing is running the theme through Coding Standards, right now at least. Happy to make any adjustments after discussion during this week's meeting.
|
For future reference, as this needs discussion, I would have suggested an issue would have been great to create. I've tagged it for discussion as should be brought up in the weekly meeting. We have to consider the packaging implications of having this in root. |
|
Very easy to ignore from packaging via gitattributes. Super-simple. Happy to chat through it during the first meeting.
|
| <description>A custom set of code standard rules to check for WordPress themes.</description> | ||
|
|
||
| <!-- Include the WordPress ruleset, with exclusions. --> | ||
| <rule ref="WordPress"> |
westonruter
Aug 31, 2015
Member
@philiparthurmoore this should be WordPress-Core instead, as WordPress is a superset of all the standards and it has a lot of extras that wouldn't be applicable.
There's also, actually, a WordPress-Docs standard now too which can be used to check for PhpDoc comments.
So I think this should be replaced with:
<rule ref="WordPress-Core" />
<rule ref="WordPress-Docs" />
@philiparthurmoore this should be WordPress-Core instead, as WordPress is a superset of all the standards and it has a lot of extras that wouldn't be applicable.
There's also, actually, a WordPress-Docs standard now too which can be used to check for PhpDoc comments.
So I think this should be replaced with:
<rule ref="WordPress-Core" />
<rule ref="WordPress-Docs" />
| # Install CodeSniffer for WordPress Coding Standards checks. | ||
| - git clone https://github.com/squizlabs/PHP_CodeSniffer.git php-codesniffer | ||
| # Install WordPress Coding Standards. | ||
| - git clone https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards.git wordpress-coding-standards |
westonruter
Aug 31, 2015
Member
@philiparthurmoore since develop is set to be the default branch for WordPress-Coding-Standards, this should probably clone explicitly checking out master for the latest stable release.
git clone -b master https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards.git wordpress-coding-standards
Also, you could get a speed boost by grabbing the tarball instead:
mkdir wordpress-coding-standards && curl -L https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards/archive/master.tar.gz | tar xz --strip-components=1 -C wordpress-coding-standards
@philiparthurmoore since develop is set to be the default branch for WordPress-Coding-Standards, this should probably clone explicitly checking out master for the latest stable release.
git clone -b master https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards.git wordpress-coding-standardsAlso, you could get a speed boost by grabbing the tarball instead:
mkdir wordpress-coding-standards && curl -L https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards/archive/master.tar.gz | tar xz --strip-components=1 -C wordpress-coding-standards| # Hop into themes directory. | ||
| - cd $theme_dir | ||
| # After CodeSniffer install you should refresh your path. | ||
| - phpenv rehash |
westonruter
Aug 31, 2015
Member
Also can install JSHint and JSCS:
- npm install -g jscs
- npm install -g jshint
Also can install JSHint and JSCS:
- npm install -g jscs
- npm install -g jshint
westonruter
Aug 31, 2015
Member
And grab the Core JSHint file:
- wget https://develop.svn.wordpress.org/trunk/.jshintrc
And grab the Core JSHint file:
- wget https://develop.svn.wordpress.org/trunk/.jshintrc| # -n flag: Do not print warnings. (shortcut for --warning-severity=0) | ||
| # --standard: Use WordPress as the standard. | ||
| # --extensions: Only sniff PHP files. | ||
| - $WP_DEVELOP_DIR/php-codesniffer/scripts/phpcs -p -s -v -n . --standard=./codesniffer.ruleset.xml --extensions=php |
westonruter
Aug 31, 2015
Member
This can also add JSHint and JSCS checks:
- jshint .
- jscs --preset wordpress $( find . -name '*.js' )
This can also add JSHint and JSCS checks:
- jshint .
- jscs --preset wordpress $( find . -name '*.js' )
|
Closing in favor of #140. |
There will no doubt be a ton of pull requests that come in for Twenty Sixteen, and with every PR that comes in, there’s a chance that something can break. One of the great things about GitHub / Travis CI for Twenty Sixteen is that we can now automatically check if someone’s pull request is a good one (at least in the eyes of automation) and then act on it.
This pull request introduces an empty scaffold for automated testing into 2016; the decisions on which coding standards rules to ignore or not ignore will be left up to later discussions, so please consider this PR to address and only address the very real need to automatically test the vast number of PRs that we can expect to receive in the coming weeks for the new default theme.
This will require someone from the WordPress team to turn the switch on for this in Travis CI. A Magnum CI alternative can be created if people aren’t too keen on Travis CI for whatever reason.
Errors on initial scaffolding can be found here:
https://travis-ci.org/philiparthurmoore/twentysixteen/jobs/77820981