Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 18:27
    mib32 commented #148
  • Oct 24 2019 10:04
    wrozka opened #159
  • Oct 09 2019 03:24
    pwim commented #129
  • Oct 09 2019 03:22
    pwim opened #158
  • Sep 16 2019 01:20
    matiasgarciaisaia commented #129
  • Sep 13 2019 13:06
    umerebryx commented #129
  • Sep 12 2019 15:26
    matiasgarciaisaia commented #129
  • Sep 12 2019 11:42
    umerebryx commented #129
  • Aug 28 2019 17:49
    matiasgarciaisaia commented #129
  • Aug 28 2019 07:09
    umerebryx commented #129
  • Aug 27 2019 12:36
    umerebryx commented #129
  • Jul 01 2019 12:58
    bmedici opened #157
  • Jun 27 2019 04:34
    ndorfin closed #153
  • Apr 27 2019 19:44
    bkazez commented #138
  • Oct 07 2018 04:02
    ikuwow opened #156
  • Oct 02 2018 14:15
    hobodave commented #154
  • Aug 19 2018 13:55
    TheSmartnik opened #155
  • Jul 25 2018 13:40
    lacostej opened #154
  • Jul 16 2018 11:38
    bmedici commented #108
  • Jul 09 2018 05:22
    ndorfin edited #153
Frederic Jean
@fredjean
odd... Where is the s3_sync configuration?
Gabe Kopley
@gkop
Oh it's just what I copied from the readme
Frederic Jean
@fredjean
Ah.
Gabe Kopley
@gkop
I left it off cause I didn't want to filter
Frederic Jean
@fredjean
Yeah, credentials are hard too.
Gabe Kopley
@gkop
teehee
Frederic Jean
@fredjean
Try moving the relative asset and asset hash activation outside of the build configuration.
My guess is that the path generated in the build phase are different from the path generated when it is time to sync.
I should look for a way ot apply the build configuration when s3_sync is started.
Gabe Kopley
@gkop
Yes you got it.
Unless I plan on upgrading to MM4, anyreason not to use 3.0 of s3_sync?
Frederic Jean
@fredjean
You should be fine.
Gabe Kopley
@gkop
Cause the separation of development, build, shared, etc is one of the really nice features of MM
Frederic Jean
@fredjean
MM4 has some serious API changes.
But s3_sync 3.0.x should keep running on MM3.x
Gabe Kopley
@gkop
I know, they broke the feature that spits out all the different js files in development, but one file in build, for example. That's an old feature from the early days of rails asset pipeline and always worked since I can remember in MM
Thanks for your help!
Frederic Jean
@fredjean
I just created #89 to see whether I can load the config.
I'll have some airport/hotel time this week that I can use for this.
Gabe Kopley
@gkop
Rad, I will try and QA the patch when it comes out :) Thanks!!!
Frederic Jean
@fredjean
You are welcome!
Frederic Jean
@fredjean
Turns out it was easier than I thought. I'll push the fix to master tonight and I will release 3.3.1 at some point tomorrow...
Frederic Jean
@fredjean
The fix is on the master branch.
Frederic Jean
@fredjean
@gkop ^^^ if you want to give it a go.
Matias Garcia Isaia
@mgarciaisaia
Hi everyone! I'm trying to set a custom 4xx error document to an S3 bucket hosting a static website, and I feel this gem should do it. Am I right?
I think there's nothing implemented, but - does that behaviour belong here? Would it be accepted if I make a PR for that?
I think fog already has some kind of support for doing that - it may just require me to ask it to do it from this extension
Frederic Jean
@fredjean
It's a configuration item on the bucket right?
I'll gladly look at a PR that would implement such thing...
We already toggle versioning and encryption.
Matias Garcia Isaia
@mgarciaisaia
For what I understand - haven't tested it yet - this lines do the trick
Frederic Jean
@fredjean
Setting the index document and error document makes sense in our context.
Matias Garcia Isaia
@mgarciaisaia
It was in the main fog gem some versions ago - the method exists in some version of fog that my current s3_sync version is using
Great - I hope I'll bring news about this soon :)
Frederic Jean
@fredjean
Cool.
Matias Garcia Isaia
@mgarciaisaia
@fredjean I'm still using middleman 3.3 (not 4.0 previews). What version of s3_sync should work on?
Frederic Jean
@fredjean
I'll cut a branch for the 3.3.x stream.
@mgarciaisaia I have just cut a v3.3.x branch based on the v3.3.3 tag. Feel free to work against that branch.
Matias Garcia Isaia
@mgarciaisaia
Great.
Frederic Jean
@fredjean
The 4.0.0 release was a little premature...
I'll cherry-pick your changes into master as needed.
Matias Garcia Isaia
@mgarciaisaia
I think I'm pretty much done - it's just that I don't have permission for the S3 bucket I'm testing on
Frederic Jean
@fredjean
Details... ;)
Matias Garcia Isaia
@mgarciaisaia
Yeap.
I've been kind-of-testing, but then there's the permissions issue. So I've tried every path that doesn't work, only the right one is left :P
Frederic Jean
@fredjean
It's progress :)
Matias Garcia Isaia
@mgarciaisaia
If you want to try it, I think it's ready: https://github.com/matiasgarciaisaia/middleman-s3_sync/tree/custom-error-document
I'll make the PR over 3.3.x tomorrow after testing it actually works - but the new release should be v3.4.0, I think, as the new features won't work in older versions of the extension.
The same commit should work if cherry-picked on master, I think.
Frederic Jean
@fredjean
I would argue that making the default index.html and 404.html would make sense...
ah, you are setting the default index document setting further down...
I'll have a deeper look at it tomorrow morning. I'm about to crash...
Matias Garcia Isaia
@mgarciaisaia

Yeah - the default is not to do anything. If you want to change any of both, you must set the Index Document - ie, only the Error Document is optional. That's why they default to nil - to tell when you actually want the index to be index.html apart from when you aren't specifying it.
As the index.html thing is not an AWS default, you can't compare config.index_suffix with "index.html" to distinguish those situations.

But that would be tomorrow's issues. Now it's bed time!