Closed mrdavidlaing closed 11 years ago
@david-coombes How about this task as a very simple start to the a grunt verify module. If it gets to a sufficient level of complexity / reusability, then perhaps we could extract it.
What other things should we check?
some builds also have config file checks - apache httpd, a parameter to specify these commands could be very useful as well. Think the only way we can definitely test is through exit codes from the builds which makes its fairly simple to start of with,
if exit code isn't true:
throw error message
if test_command
if not (run test_command)
throw error message
continue
"now I had a "crazy" idea for a project. A node.js adapter for Ant so you can call any task as a JS method passing JSON configs" http://blog.millermedeiros.com/node-js-ant-grunt-and-other-build-tools/
going to look at plain node.js as a build tool outside of grunt
I think this article makes a good case for not going down the declarative route; but I don't think that throwing out everything and writing your own is the right approach either. In fact, he even says:
It will take an absurd amount of time before all the relevant tasks present on battle tested tools like Ant, Maven, Gradle
Rather than looking at writing your own build tool from scratch, rather look at one of the other battle tested
build tools; like rake
Yeah, interesting article with a lot of good points and also a few weaknesses indeed, another one from my point of view:
If a task “depends” on another one you can simply call the other method before executing it or use something like Async.js to run the tasks in parallel or in sequence.
That's a gross simplification of the problem at hand, insofar the key of a dependency mechanism is avoiding the same tasks being called multiple times and figuring out the smartest execution plan/order instead (which is the default behavior within all decent build tools I know, i.e. you might want to execute a dependency for every dependent, but that's very rare and should be a deliberate thing in case).
just thinking another point to stew about is the end developers. As this is wordpress specific, the end developers are going to be plugin/theme developers - thus the popular scripting languages like, js, php etc (also especially if it becomes popular for building/maintaining mutliple projects(plugins/themes) by one developer and not just teams. Think this might be the only disadvantage to using rake but worth considering.
Merging this PR to keep the ball rolling. We currently have a simplistic notion of a "verify-hosting-dependancies" task; which can be expanded / refactored at a future date when it becomes clearer what to do.
The
verify-hosting-dependancies
task checks that everything required to launch the dev instance of WordPress (eg, MySQL) has been installed, and if not, fails thegrunt run
task with a helpful error message.eg: