search

xwp / wp-plugin-dependencies

WordPress plugin dependency management.
http://wordpress.org/plugins/plugin-dependencies/
88 stars 16 forks source link

QA update needed #50

Open jrfnl opened 6 years ago

jrfnl commented 6 years ago

This plugin has basically been dormant for the past three years, but should still work.

To test this and potentially tweak the plugin for compatibility with newer WP versions, the build checks would need to start passing again.

So, to fulfill this prelim requirement, I would identify the following actions:

  1. Either update the dev-lib submodule or remove it in favour of having a native Travis script. :point_right: As this plugin does not have unit tests, nearly all of the scripts being run via dev-lib are redundant and create builds which don't test anything new. IMHO all that is needed is:
    • linting against each supported PHP version
    • running PHPCS against WPCS and PHPCompatibility on one PHP version Those two tasks can be just as easily accomplished without the overhead of the dev-lib submodule.
  2. Create a custom PHPCS ruleset which adds the recommended properties for WPCS.
  3. Update the code to comply with the latest stable WPCS guidelines.

I'll happily send in a PR for this, but need a decision on point 1, which is why I've created this issue to discuss this.

/cc @westonruter

westonruter commented 6 years ago

@jrfnl To avoid duplicating logic for running the tests, I think dev-lib should be retained. It cam handle the phpcs and php linting, but also the readme.md generation and also it has a the pre-commit hook. If we want to disable phpcs from running on a given job, we can just add DEV_LIB_SKIP=phpcs to the env, or as you say we could just have one single job that runs PHPCompatibility.

jrfnl commented 6 years ago

@westonruter I defer to your judgement in this.

The build against the old version of the submodule errors out, but after updating the submodule, the build still errors. The failures are to do with the DEV-LIB config, the actual tests aren't even being run.

I'll have another look at it, but may need some help to get it back up and running.

westonruter commented 6 years ago

I'll try to update the submodule and the .travis.yml config sometime over the next week.

jrfnl commented 6 years ago

@westonruter That would be great. I've got the CS changes needed ready locally, so I can pull that as soon as Travis is up and running again.

If you like, I can push the WIP branch with the submodule update and other config changes I did as well. I didn't get it all working again, but having that branch as a base might save you some time.

jrfnl commented 6 years ago

Ok, gave it one more try when prepping my WIP branch to be pushed here and lo and behold, I've got it working.

I still think the build could be further optimized as it still pulls in more things than are needed, but for now I'll prepare a PR with what I've got.

If you like, you can then add commits to it to further optimize the build.

westonruter commented 6 years ago

Sure, go ahead

jrfnl commented 6 years ago

Cleaning things up as we speak.

P.S.: looks like I'll also be sending some PRs to the dev-lib repo....

mikelking commented 6 years ago

Very cool to see this getting some love as well as seeing how the pro's do things. ;)