Add webhook call on successful sync about git-sync HOT 18 CLOSED

Thanks for keeping the ball rolling. Looking forward to the next iteration.

from git-sync.

Hey @andjelx are you working on this ?

I just started doing it today because, well having a very similar usecase..
https://github.com/emirozer/git-sync/commit/5aaffadae52ee201ff40dc78704373453ec12880
Its initial work only at the moment, so I'm gonna test & see if i can add something to the testing process about the hook as well. Do let me know if you already made progress?

from git-sync.

Actually I made it, it’s in my fork, but haven’t received any feedback here to raise a PR :(

from git-sync.

People are busy I guess :) why not raise the PR and discuss there, since it is going the be a very small change-set without side-effects to actually syncing ?

Ofc I'm not a maintainer so, no disrespect 🍻

from git-sync.

Initiated: #85

from git-sync.

Commented on the PR. Future feature issues might take a bit longer to respond due to priorities.

from git-sync.

Sorry, it's been a hellish few weeks for me. Will look at the PR. In general I don't have a problem with this, but I'd prefer fewer flags. What about something like --webhook='{"url": "http://localhost:1234/reload", method="POST", success=200}' - that block can be parsed as JSON, with unspecified keys having default values.

Unclear if success should be a specific code or a range.

from git-sync.

@thockin
Your flags approach a good idea, but I just followed the same approach as in original code + technically passing ENV vars might be easier to use with K8 Deployments.

For now: success code is one code (not a range)

from git-sync.

@thockin What if we would go with existing approach with flags, then migrate to your approach ?

from git-sync.

@andjelx that would already introduce them to the user and make the "upgrade" not backwards compatible.

from git-sync.

@stp-ip good point... I need then to dig more into Go then (as mostly on Python) how to process JSONs

from git-sync.

@stp-ip, @thockin I have updated PR. Could you please have a look?

from git-sync.

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.

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

from git-sync.

/remove-lifecycle stale

from git-sync.

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.

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

from git-sync.

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

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 rotten

from git-sync.

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

from git-sync.

@fejta-bot: Closing this issue.

from git-sync.