Change permissions on copied file so subsequent deploys work. #250
Conversation
|
Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at [email protected]. Thanks! |
|
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks! |
|
👍 I was going to say, can we add a test to make sure this behavior is preserved in the future, but I'm not sure where to add that test ... :S |
|
@danielrhodes We just merged #254 which solves this at the root I think -- that PR removed the whole copy-on-boot workflow and replaced it by adding different paths to Sprockets based on your settings. I think that's a much cleaner flow. Could you try on master and see if that works in your case? |
|
Please let me know if this new solution doesn't work for your case! |
In some production environments, the permissions of the copied file were not being set in a way where subsequent deploys could overwrite the files if necessary. This sets the initial permissions of the two problematic files so that subsequent deploys do not run into this permissions issue.
Fixes #175