• Resolved Never Settle

    (@neversettle)


    FYI including your phpunit folder in the public version of the plugin is probably not a great idea. It breaks codeship.io build and deploy via git and bitbucket because of the way you have your require_once(‘../CountField.php’) in BuildInStats_Test.php. I know the files are indeed actually there, but when picked up for execution / validation by a continuous deployment solution like codeship it chokes with this:

    Warning: require_once(../CountField.php): failed to open stream: No such file or directory in /home/rof/src/bitbucket.org/creativetrust/jellytelly-v2/wp-content/plugins/contact-form-7-to-database-extension/phpunit/BuildInStats_Test.php on line 3

    Otherwise love your plugin. It’s great!

    https://wordpress.org/plugins/contact-form-7-to-database-extension/

Viewing 4 replies - 1 through 4 (of 4 total)
  • Plugin Author Michael Simpson

    (@msimpson)

    Thanks for letting me know. Is there a way to still include the files w/o using “../” that would work?

    I’m curious how you are using codeship.io. Do you put a whole WordPress installation for a website there? Do you use it for building WP plugins and themes?

    Thanks

    Thread Starter Never Settle

    (@neversettle)

    That’s a good question. I had a theory that it should be doable, but couldn’t really take the time to play with it. My theory was that something like…

    require_once( dirname( __FILE__ ) . '/CountField.php' );

    …might work. I know it would be a pain to pull the directory every time you want to push an update. Although it would be super easy just to create an svn:ignore for that directory and always have it on your local repo but not push with the rest.

    We use codeship for deploying client projects. It is probably overkill to use it just for building themes and plugins, and for those we just use a regular repo on bitbucket. Codeship is more for validated deployment to live, operational sites or web apps to facilitate continuous deployment. Our full workflow in that case looks like this at a very high level:

    1. dev locally with a full wordpress site in a repo
    2. the repo master is on bitbucket and we have local forks
    3. we merge to the master repo through pull requests from our local forks (that are also on bitbucket)
    4. when a merge from pull request happens on bitbucket it uses a hook to trigger a build on codeship
    5. codeship validates all the php, runs any phpunit tests defined in the project, executes our custom commands like grunt to minify css, less, js, and runs the git commands to push the validated end result to the live server in real-time

    If it hits any errors in that process it halts the build so that bugs are not introduced into the live site / app. It’s pretty awesome. There are other tools that will achieve basically the same thing, and we don’t have any experience with them, but codeship has been great.

    It’s only git though. So it wouldn’t be possible to deploy to wp.org that way (which like I said would probably be overkill anyway). However, it would probably be possible to do something like that with another tool.

    There’s a great comparison of all the major ones out there here:
    http://en.wikipedia.org/wiki/Comparison_of_continuous_integration_software
    which lists CSM compatibility for each if you’re interested in digging into it more.

    All the best!
    NS

    Plugin Author Michael Simpson

    (@msimpson)

    Thanks for all the extra info!

    I tried to fix the includes in version 2.8.9.

    Thread Starter Never Settle

    (@neversettle)

    Sure thing! Thanks!

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘phpunit folder included in latest version breaks deployment’ is closed to new replies.