Add non atomic behaviour

[stp-ip]

Add flag and logic to disable symlink usage and just pull in new changes via git pull.

This could be used as a workaround for various issues and additional use-cases, but introduces inconsistent state so this should be heavily warned about.

Flag: GIT_SYNC_ATOMIC

[ursuad]

Maybe an option here would be to introduce a hook which will get triggered once the pull (update) is successful?
For example calling a configurable REST endpoint ( notify ) once the update is complete. This way, it would be really easy to create a wrapper around third party tools that want to use the git-sync functionality.

The third party tools would get notified once the update is complete. This would partly eliminate the need for non atomic behaviour.

[thockin]

That could be workable

…

On Tue, Apr 4, 2017 at 10:07 AM, Adrian Ursu ***@***.***> wrote: Maybe an option here would be to introduce a hook which will get triggered once the pull (update) is successful? For example calling a configurable REST endpoint ( notify ) once the update is complete. This way, it would be really easy to create a wrapper around third party tools that want to use the git-sync functionality. The third party tools would get notified once the update is complete. This would partly eliminate the need for non atomic behaviour. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#53 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFVgVI-2Cm3e5bSGJRTWrSTlqZXug9ffks5rsnjKgaJpZM4MlNrv> .

[stp-ip]

Do we want to add triggering to git-sync?
What trigger should be used? http, touch ready.file, etc.?
Should we still provide a non atomic option?

[thockin]

I'd be OK with adding triggers - both HTTP get and file touch seem OK. I would not add non-atomic, unless there's significant pain being caused by symlinks. I haven't looked closely.

…

On Tue, Apr 4, 2017 at 11:44 AM, Michael Grosser ***@***.***> wrote: Do we want to add triggering to git-sync? What trigger should be used? http, touch ready.file, etc.? Should we still provide a non atomic option? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#53 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFVgVJiR82Zq0iporS06mrEpAHiYIZnkks5rso-NgaJpZM4MlNrv> .

[stp-ip]

One of the pain points of symlinks are programs using notify "different" following symlinks and not checking for symlink changes itself. hugo for example.

[thockin]

I am fine with non-atomic mode, if people really can't work around it, but maybe we could fix Hugo ?

…

On Tue, Apr 4, 2017 at 12:14 PM, Michael Grosser ***@***.***> wrote: One of the pain points of symlinks are programs using notify "different" following symlinks and not checking for symlink changes itself. hugo for example. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#53 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFVgVMsFSVJv1OqIkV3vPRPwLPzqFMp3ks5rspaJgaJpZM4MlNrv> .

[japettyjohn]

This would help when the folder becomes the CWD of the app for Go, not sure if this is the same problem in Hugo. In my case the symlink is dereferenced which then leads to explosions when it references a relative file from the non-existent folder.

Another option would be to replace the old folder with a symlink to the new folder. The notification should still be added so things can get reloaded as needed.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[thockin]

/lifecycle frozen
/remove-lifecycle stale

[thockin]

Do you think #110 would cover this need?

[stp-ip]

It doesn't solve it perfectly, but it gives a good workaround I guess. After merge I can take another look and maybe write up some ideas.