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

On Tuesday, June 18, 2013 11:47:47 AM UTC-7, Shahar Kedar wrote:
>
> 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.
>
>
> On Tue, Jun 18, 2013 at 9:36 PM, Shahar Kedar <[email protected] 
> <javascript:>> wrote:
>
>> 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. 
>>
>> On Tue, Jun 18, 2013 at 8:37 PM, Michael DeHaan <[email protected] 
>> <javascript:>> wrote:
>>
>>> Please show me an example of the grunt command vs the Ansible command in 
>>> this case, preferably several examples?
>>>
>>>
>>>
>>>
>>> On Tue, Jun 18, 2013 at 10:33 AM, Shahar Kedar <[email protected] 
>>> <javascript:>> wrote:
>>>
>>>> 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...)
>>>>
>>>>
>>>> On Tue, Jun 18, 2013 at 5:50 PM, Michael DeHaan <
>>>> [email protected] <javascript:>> wrote:
>>>>
>>>>> 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!
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Jun 17, 2013 at 10:27 PM, Shahar Kedar <[email protected] 
>>>>> <javascript:>> wrote:
>>>>>
>>>>>> 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 <https://github.com/gruntjs/grunt>) 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 
>>>>>> <https://github.com/skvidal/ansible-contrib>, right?), and if you're 
>>>>>> still not convinced, then I'll put it there. 
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jun 17, 2013 at 6:54 AM, Michael DeHaan <
>>>>>> [email protected] <javascript:>> wrote:
>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jun 14, 2013 at 7:22 AM, Shahar Kedar <[email protected] 
>>>>>>> <javascript:>> wrote:
>>>>>>>
>>>>>>>> I was thinking of implementing a Grunt <http://gruntjs.com/>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
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> 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 [email protected] <javascript:>.
>>>>>>>>
>>>>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>>>>  
>>>>>>>>  
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -- 
>>>>>>> Michael DeHaan <[email protected] <javascript:>>
>>>>>>> CTO, AnsibleWorks, Inc.
>>>>>>> http://www.ansibleworks.com/
>>>>>>>
>>>>>>>  -- 
>>>>>>> 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 
>>>>>>> [email protected] <javascript:>.
>>>>>>>
>>>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>>>  
>>>>>>>  
>>>>>>>
>>>>>>
>>>>>>  -- 
>>>>>> 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 [email protected] <javascript:>.
>>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>>  
>>>>>>  
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Michael DeHaan <[email protected] <javascript:>>
>>>>> CTO, AnsibleWorks, Inc.
>>>>> http://www.ansibleworks.com/
>>>>>
>>>>>  -- 
>>>>> 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 
>>>>> [email protected] <javascript:>.
>>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>>  
>>>>>  
>>>>>
>>>>
>>>>  -- 
>>>> 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 [email protected] <javascript:>.
>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>  
>>>>  
>>>>
>>>
>>>
>>>
>>> -- 
>>> Michael DeHaan <[email protected] <javascript:>>
>>> CTO, AnsibleWorks, Inc.
>>> http://www.ansibleworks.com/
>>>
>>>  -- 
>>> 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 
>>> [email protected] <javascript:>.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>  
>>>  
>>>
>>
>>
>

-- 
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 [email protected].
To post to this group, send email to [email protected].
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.

Reply via email to