[Gerrit 2.14]is there is a way to stop the change from getting merged from the "change-merged" hook?

[William]

Hello

I am using gerrit 2.14 and am wondering if there is a way to stop the change from getting merged from the "change-merged" hook? does "change-merged" hook run only after a change is merged?

[Gert van Dijk]

On Wednesday, 20 February 2019 19:26:21 UTC+1, William wrote:

I am using gerrit 2.14 and am wondering if there is a way to stop the change from getting merged from the "change-merged" hook? does "change-merged" hook run only after a change is merged?

I believe this is answered in the hooks plugin's documentation:

With the exception of the commit-received and ref-update hooks, hooks are run in the background after the relevant change has taken place so are unable to affect the outcome of any given change. Because of the fact the hooks are run in the background after the activity, a hook might not be notified about an event if the server is shutdown before the hook can be invoked.

 

However, I think the listing of "commit-received and ref-update" should actually also include "submit", because the hooks listing page describes that you can block submits with it:

submit 

This is called when a user attempts to submit a change. It allows the submit to be rejected. 

If the hook exits with non-zero return code the submit will be rejected and the ouput from the hook will be returned to the user.

If you need to configure conditions for allowing changes to be merged, there are more ways to accomplish that. It depends pretty much on your use case, so please explain a bit more about it so we can advise you better. (See also for example, Issue 2610, where this is discussed.)

HTH

[William]

@Gert:

I have the info you mentioned ,thats why I specifically asked if the submit can be rejected from the "change-merged" hook

My use case is that  from my change-merged hook I cherry-pick the change being MERGED to other branches but the cherry-picked changes end up in merge conflicts and developers don't resolve them in a timely manner, so to be able to force developers to resolve the merge conflicts I want to make use of "topic" field to do atomic merge (ALL or NOTHING gets MERGED) including the original gerrit being MERGED, basically block the original change from being MERGED


So, for my use case I need to be able to reject merging(submiting) a change from the "change-merged" hook (I know I can do it from other hooks like "submit" but there is no "submit" hook in gerrit 2.14 ) .

[Martin Fick]

On Wednesday, February 20, 2019 3:11:30 PM MST William wrote:
> @Gert:
>
> I have the info you mentioned ,thats why I specifically asked if the submit
> can be rejected from the "change-merged" hook
>
> My use case is that from my change-merged hook I cherry-pick the change
> being MERGED to other branches but the cherry-picked changes end up in
> merge conflicts and developers don't resolve them in a timely manner, so to
> be able to force developers to resolve the merge conflicts I want to make
> use of "topic" field to do atomic merge (ALL or NOTHING gets MERGED)
> including the original gerrit being MERGED, basically block the original
> change from being MERGED
>
>
> So, for my use case I need to be able to reject merging(submiting) a change
> from the "change-merged" hook (I know I can do it from other hooks like
> "submit" but there is no "submit" hook in gerrit 2.14 ) .

I suspect that what you are trying to achieve is better done via a CI system
that can check if there is an existing change for each branch you care about,
and whether that change can currently be merged to that branch. Once all the
changes pass, you can give the change a V+1, else V-1.

-Martin

--
The Qualcomm Innovation Center, Inc. is a member of Code
Aurora Forum, hosted by The Linux Foundation

[William]

@Martin:There could be other ways to do it but thats not what I am looking for,am looking do it through gerrit hooks rather than building a whole new system,I dont want to side-track this discussion

I want to know  if there is a way to stop the change from getting merged from the "change-merged" hook? I want to stick to this dicussion

[David Pursehouse]

On Thu, Feb 21, 2019 at 10:05 AM William <bacha....@gmail.com> wrote:

@Martin:There could be other ways to do it but thats not what I am looking for,am looking do it through gerrit hooks rather than building a whole new system,I dont want to side-track this discussion

I want to know  if there is a way to stop the change from getting merged from the "change-merged" hook? I want to stick to this dicussion

No, this is not possible.  When the "change-merged" hook is invoked, the change has already been merged and the hook is invoked asynchronously.

 

On Wednesday, February 20, 2019 at 4:11:48 PM UTC-8, MartinFick wrote:

On Wednesday, February 20, 2019 3:11:30 PM MST William wrote:
> @Gert:
>
> I have the info you mentioned ,thats why I specifically asked if the submit
> can be rejected from the "change-merged" hook
>
> My use case is that  from my change-merged hook I cherry-pick the change
> being MERGED to other branches but the cherry-picked changes end up in
> merge conflicts and developers don't resolve them in a timely manner, so to
> be able to force developers to resolve the merge conflicts I want to make
> use of "topic" field to do atomic merge (ALL or NOTHING gets MERGED)
> including the original gerrit being MERGED, basically block the original
> change from being MERGED
>
>
> So, for my use case I need to be able to reject merging(submiting) a change
> from the "change-merged" hook (I know I can do it from other hooks like
> "submit" but there is no "submit" hook in gerrit 2.14 ) .

I suspect that what you are trying to achieve is better done via a CI system
that can check if there is an existing change for each branch you care about,
and whether that change can currently be merged to that branch. Once all the
changes pass, you can give the change a V+1, else V-1.

-Martin

--
The Qualcomm Innovation Center, Inc. is a member of Code
Aurora Forum, hosted by The Linux Foundation

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gert van Dijk]

On Thursday, 21 February 2019 00:11:30 UTC+1, William wrote:

I have the info you mentioned ,thats why I specifically asked if the submit can be rejected from the "change-merged" hook

My use case is that  from my change-merged hook I cherry-pick the change being MERGED to other branches but the cherry-picked changes end up in merge conflicts and developers don't resolve them in a timely manner, so to be able to force developers to resolve the merge conflicts I want to make use of "topic" field to do atomic merge (ALL or NOTHING gets MERGED) including the original gerrit being MERGED, basically block the original change from being MERGED

Thanks for the background information. I felt like I had already seen this this discussion on the mailing list, please consider posting in the same thread next time for context. https://groups.google.com/d/msg/repo-discuss/s8xXOTuanhg/1nHwNCaxGgAJ

 

So, for my use case I need to be able to reject merging(submiting) a change from the "change-merged" hook (I know I can do it from other hooks like "submit" but there is no "submit" hook in gerrit 2.14 ) .

There is! Just update your hooks plugin to the latest one in stable-2.14. Docs link for that version:

https://gerrit.googlesource.com/plugins/hooks/+/refs/heads/stable-2.14/src/main/resources/Documentation/hooks.md#submit

(And, if you want <features>, you might want to make it yourself easier by prioritizing Gerrit updates too.)

On the bigger picture of your problem description I agree with Martin here and wanted to elaborate a bit more on why I think so.

A CI or CI-like script could do the checks you want to do and post verdict to a dedicated label. Could be as easy as a script/service listening on stream-events waiting for the new changes to come by, performing a simple query if a change matches your filter, then vote depending on the outcome.

It would be possible for users to see which of their changes are blocked (queriable), why their change is blocked (via label configuration) before they attempt to submit and it would be possible to set ACLs to let certain people overrule it. It would also take out all the complexity from Gerrit hooks which are run synchronously and, resulting in a better performance and less error prone configuration. (A failing hook could block all your submits, even those you didn't mean to check even! With a label configuration only those projects-branches combinations configured as such would be affected in case of errors with your custom checks.)

HTH

 

[William]

@Gert:

I would like to ask why you suggest using a ":A CI or CI-like script " ,why not gerrit hooks?  I know you mentioned not to block all submissions but I want to get more details on when would it mandate a CI system(Script) as opposed to doing it in gerrit hooks outside of the problem at hand,I have been trying to find a justifiable answer for this for long on why to build a seperate CI system when we can use Gerrit hooks to do the job

[Martin Fick]

On Thursday, February 21, 2019 3:22:15 PM MST William wrote:
> @Gert:
> I would like to ask why you suggest using a ":A CI or CI-like script " ,why
> not gerrit hooks? I know you mentioned not to block all submissions but I
> want to get more details on when would it mandate a CI system(Script) as
> opposed to doing it in gerrit hooks outside of the problem at hand,I have
> been trying to find a justifiable answer for this for long on why to build
> a seperate CI system when we can use Gerrit hooks to do the job

Gerrit hooks are single threaded and queued. If the server goes down, your
queued hooks will be lost. For asynchronous hooks, you will then not be able
to recover.

If it is a synchronous hook that will block a Gerrit action, then the loss may
be appropriate. For synchronous hooks, any delay in the hook will delay the
server operation.

I don't remember how synchronous hooks interact with the asynchronous ones, I
assume they don't (check the code).

We developed some scripts a long time ago to queue our asynchronous hooks
outside of Gerrit using the filesystem so they will not be lost on server
exit. It works fairly well, but likely is more than one most people want.
Without it however, asynchronous are not very production resilient,

[Gert van Dijk]

On Friday, 22 February 2019 00:22:16 UTC+1, William wrote:

@Gert:

I would like to ask why you suggest using a ":A CI or CI-like script " ,why not gerrit hooks?  I know you mentioned not to block all submissions but I want to get more details on when would it mandate a CI system(Script) as opposed to doing it in gerrit hooks outside of the problem at hand,I have been trying to find a justifiable answer for this for long on why to build a seperate CI system when we can use Gerrit hooks to do the job

 I think I had extensively listed the reasons already in my previous message, but I'll repeat them bullet-wise then:

• It would be possible for users to see which of their changes are blocked (queriable), before attempting submission.
  
• + why via label configuration
  
• Ability to set ACLs to let certain people overrule.
• Take out all the complexity from Gerrit hooks as monolithic logic as they are run synchronously (as also explained more by Martin just now)
  
• above also results in a better performance/scalability
• less error prone. A failing hook could block all your submits, even those you didn't mean to check even! With a label configuration only those projects-branches combinations configured as such would be affected in case of errors with your custom checks.

So, yeah of course hooks can do the job in your case, but be sure to understand the consequences & benefits.

HTH