Provide an array back listing the file actions and details.

[rainabba]

I didn't see that this is available and admittedly haven't dug into code yet, but I wanted to get the ball rolling just in case because that output object would be very useful for other operations such as here: mllrsohn/grunt-invalidate-cloudfront#9

Accepting a callback or returning a promise that could be passed this object would be a great approach too.

[MathieuLoutre]

Hi there!
Indeed, there's a variable objects in the code that keeps track of what needs to be uploaded etc. If you had this array you could probably do what you want to do.
However, I couldn't find anything in the docs about how to return an object. I could have a callback as an option or maybe expose it on the options object (provided the options function of grunt doesn't make a copy) so you could access it from there.

If you want to experiment, the array is called objects and you want to do that in the drain function.

Let me know how it goes!

[MathieuLoutre]

Any luck @rainabba?

[MathieuLoutre]

@rainabba I'm quite interested in this if you made any discoveries. I'm closing this for now, but feel free to re-open.

[MathieuLoutre]

@rainabba Just to let you know this feature finally made it into the plugin. It now exports a variable on the grunt config with the list of changed files.

[rainabba]

Great timing for me as my work with S3 is going to resume as of about 2 hours ago so thanks!

[ianpogi5]

any examples on how to use aws_s3_changed in the gruntfile?

[MathieuLoutre]

Haven't used that personally, but you should be able to get what the list of files through runt.config.get('aws_s3_changed') and pass that onto an invalidation plugin.

[ianpogi5]

Is this what you mean?

invalidate_cloudfront: {
            options: {
                key: 'XXX',
                secret: 'XXX',
                distribution: 'xxx'
            },
            production: {
                files: grunt.config.get('aws_s3_changed')
            }
        }

[MathieuLoutre]

That's what I would try first, yes. Yet, I'm not sure what format grunt-invalidate-cloudfront expects for files, but it might just work. If not, you may have to map over the array of changed files and provide the changed files.

Additionally, you probably want to check that grunt.config.get('aws_s3_changed') isn't called at runtime but when invalidate cloudfront is called, otherwise there's every chance it'll be empty.

[ianpogi5]

Here's the error that I got

Running "invalidate_cloudfront:production" (invalidate_cloudfront) task
Invalidating 0 files: (none)

0 Completed and 0 In Progress invalidations on: XXX

Creating invalidation for 0 files
Fatal error: Your request contains one or more invalid invalidation paths.

Looks like it's empty. :-(

[pr1ntr]

so does this just not work?

[MathieuLoutre]

Well, in theory it should work, but in practice it might be hard to pass that info to another plugin if grunt.config.get('aws_s3_changed') is called at runtime, since that array is going to be empty until grunt-aws-s3 finishes. Hope that makes sense. If you could stick a function in that files property, I'm pretty sure it would work.

[pr1ntr]

First thing i tried was

"files" : function () {
   return grunt.config.get('aws_s3_changed');
}

no dice :(

[MathieuLoutre]

As in, it crashes or it returns an empty array?
Can you log the time inside that function, just to make sure it's called after the aws task has run?

[pr1ntr]

It's empty. I'll do my best a little later. Been really busy.

[MathieuLoutre]

Sure! Thanks for testing :)

On 19 Apr 2016, at 20:12, pr1ntr [email protected] wrote:

It's empty. I'll do my best a little later. Been really busy.

—
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub #35 (comment)

[deargle]

Dropping a breadcrumb: dynamic loading solution here