-
For instance, I'd like to do some logical checks with referenced issues and I'd much rather do them right there
No such extension point yet. Can you please elaborate the usage secnario in more detail?
-
Thanks for your reply.
similar to the branch protection rules, we have a strict commit-message-policy. No commit must be pushed unless it follows certain criterias. Furthermore, specific message pattern might lead to an issue status being updated
Pre-Receive checks:
- the commit-message contains a reference to an issue (KEY- or #)
- the referenced issue must not be in a closed state
- the commit-message contains a working state: "re" for work in progress or "fixed" for issue resolved
examples:
one of the checks failing leads to a push being rejected
Post-Receive routine:
- if the commit-message contains "fixed" the issue will automatically transitioned to a QA state
Process:
without a Callback Extension the process will look like
git based pre-receive-hook -> OneDev API -> extension.check(messages)with an Extension:
OneDev Git Callback -> extension.check(messages)It's all not so bad, but it would save me the burden developing/maintaining a script to call the API
-
Name Previous Value Current Value Type
Question
Improvement
-
Thanks for the elaboration. Converted as an improvement request. For the post-receive routine, you can achieve it without using scripts. Just customize appropriate issue state transition rules via
Administration / Issue Settings / State Transitions. -
Thanks for taking on this task an all your efforts, much appreciated.
-
OneDev
changed state to 'Closed' 2 years ago
Previous Value Current Value Open
Closed
-
State changed as code fixing the issue is committed (6b41acb2)
-
OneDev
changed state to 'Released' 2 years ago
Previous Value Current Value Closed
Released
-
State changed as build OD-5144 is successful
| Type |
Improvement
|
| Priority |
Normal
|
| Assignee | |
| Labels |
No labels
|
Hi Robin,
during plugin development I came across your Git Hook Calllbacks (GitPreReceiveCallback.java/GitPostReceiveCallback). I've noticed that the implementation is feeding off the "Branch Protection Rules" which might lead to a push being rejected or similar, which is nice.
However, there are some requirements which force me to do some pre-receive implementation and I was wondering if there is any chance I can hook into the callbacks from my plugin? For instance, I'd like to do some logical checks with referenced issues and I'd much rather do them right there, than calling an API-Endpoint from a script which seem to me like an unnecessary round trip.
Maybe there is already something I've been missing so far, any bind() or contribute() I can make from my plugin which would be called in addition to your callbacks?
Looking forward to your reply, Thanks - mp