Grunt Module

[Shahar Kedar]

I was thinking of implementing a Grunt module and contributing it to the core modules. Is contributing a core module as simple as developing (following the guideline of course) and sending a pull request?

If it is, where should I put it? We use Grunt for packaging, but it's multi-purpose. Could also go into web_infrastructure or a new category called "build_tools". 

Anything else I should know before I start coding?

Thanks,

Shahar

[Michael DeHaan]

I'm having a little difficulty understanding what Grunt actually is.  Seems like a Makefile replacement for node.js apps?

I'm tending to think this is something we'd just link to in the contrib section as it is probably not going to be used by x<3-5% of the userbase (which is about where the threshold of inclusion lies for core)

I'm open to being convinced otherwise, however.

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Michael DeHaan <mic...@ansibleworks.com>
CTO, AnsibleWorks, Inc.
http://www.ansibleworks.com/

[Shahar Kedar]

Grunt is a multi-purpose task executor written in Node.js but not used exclusively (or even in majority of cases) for node.js apps. Makefile replacement is a good analogy although  as a former Java developer, I personally prefer the "Ant replacement" analogy better (Ant is actually sort of a Makefile replacement so I guess it doesn't really matter :). We, and many others, use it as a build tool for web applications, or more specifically - rich client applications. For example, we use it to concat and minify JS files, to compile Jade templates, run tests etc. 

A common use case for us when deploying our application is to run Grunt after we pull the latest changes. I'm pretty sure that many (out of the ~5900) users use it for the same purpose, which makes it an integral part of their application deployment. If I had to compare it to other core modules, I would guess that Grunt is more popular then Riak (don't get me wrong - I love riak), and it gains a lot of traction.

Having said that - I'm no fanatic. I wasn't aware of the Ansible Contrib project (it's this one, right?), and if you're still not convinced, then I'll put it there. 

--
You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/J7O9V0YzdwQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ansible-proje...@googlegroups.com.

[Michael DeHaan]

There's no central ansible-contrib but we link to things from http://www.ansibleworks.com/docs/contrib.html

I guess I'm failing to understand that, if it is a makefile replacement, what the module would do to make it deserve some code around it, rather than just using the shell or command module.  In this vein, this is also why there is not a module for Make or Ant.

Can you help me understand what the module would actually do?

(As for Riak, it has quite a lot of logic in that module.)

Thanks!

[Shahar Kedar]

Hi Michael,

I admit that the grunt CLI is simple enough to be executed using the 'shell' or 'command' modules. However, the way I see it, modules can be useful not only when there's lots of logic involved, but also when there can be a more expressive or concise (or both) way of doing things. Also, a module can help 'translate' the underlying technology output to something more suitable for automation.

In the case of Grunt, this could be the execution of specific targets and tasks; passing extra arguments; pointing to a different gruntfile etc. I agree that this module won't contain complex logic, but it will IMO help developers write more expressive playbooks.

Shahar

P.S. - in this vein I certainly think that writing an Ant module might have been very beneficial (albeit nobody uses Ant anymore. I hope...)

[Michael DeHaan]

Please show me an example of the grunt command vs the Ansible command in this case, preferably several examples?

[Shahar Kedar]

Grunt: grunt build

Ansible: grunt: task=build

==================

Grunt: grunt build:debug

Ansible: grunt: task=build target=debug

==================

Grunt: grunt build:debug --gruntfile /tmp/gruntfile

Ansible: grunt: task=build target=debug file=/tmp/gruntfile

** when using the shell or command modules, the --gruntfile option will always have to be passed, otherwise grunt will not find the gruntfile (unless you do something like this 'shell: cd /myproj; grunt build:debug') 

==================

Grunt: grunt build:debug --foo=bar

Ansible: grunt: task=build target=debug foo=bar

==================

Grunt: grunt build:debug --tasks=/usr/lib/grunttasks

Ansible grunt: task=build target=debug include=/usr/lib/grunttasks

I agree that the original grunt command look very similar to the ansible commands, but I still prefer the Ansible style. 

[Shahar Kedar]

I'd like to add that I haven't (yet) tried running Grunt using the 'shell' or 'command' modules. There's a good chance that failures in the build process are not well presented when using these modules, in which case a dedicated module might also be beneficial. 

I'll let you know as soon as I know more.

[Eli Finkelshteyn]

Any update on this? I'd love to use such a module.

[Shahar Kedar]

Actually I was pretty much convinced that using the shell or command modules is good enough. We’re doing it in production already for almost a year, and we didn’t have any problems.

To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/2277a21a-7383-4d9e-a1e7-db11344fd309%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sergi Canas Galindo]

I'm trying to make a playbook wich contains a simply command that build a project and then send's the compilation result to a server. Since when you use the simple command form of ansible the playbook node that sended the command doesnt recieve the result if the command has finished or not. So sometimes the next tasks of the playbook starts even before that grunt build command finished so that make's copy only the half of the files wich creates a lot of problems.

Having grunt integrated with ansible will solve that problem because the playbook node would wait till the tasks of grunt build finish so the next task would do it's work correctly.

Of course we can put  adelay but this it's only a patch and no 100%secure to use on pro environment.

[J Hawkesworth]

Hi,

I don't know anything specific about Grunt but perhaps you could use async to kick off the grunt job and poll for completion?  http://docs.ansible.com/ansible/playbooks_async.html

Or perhaps use the wait_for module - http://docs.ansible.com/ansible/wait_for_module.html
This can wait for a file to exist so perhaps if the playbook could know the name of your build output file then this could be a way to make it only move on to next tasks when grunt has finished.

Hope this helps.

Jon