Custom conditions written in Groovy or as executable commandlines

Groovy scripts could accept the list of commits and context information (repository, enclosing commit policy, etc.) and could evaluate to TRUE or FALSE using any logic and any resource.

Have more questions? Submit a request


  • 0
    Joseph Vanvlymen

    If you are going to do this then you might as well also support non-blocking warnings as part of the exercise. The question though is what do you do in terms of issuing a warning. Clearly, a warning to the account that did the push/commit(s) makes sense but do you also send a message to another channel (e.g. Slack).

  • 0
    Tindur Hafsteinsson

    This would be really interesting to look at. In my case we're using the following:

    1) JIRA

    2) BitBucket

    3) Commit Policy Plugin

    4) Automation For JIRA (

    It would be awesome, if this plugin could offer hooks to call, e.g. from Automation For JIRA for commit related validation, and wise versa call webhooks exposed by Automation For JIRA.

  • 0
    Shahar Rotshtein

    Hey, I need to verify commits on Gitlab server. the generated jcp token - has been generated on behalf of my user. so this query: Asigenee==currentUser() cannot be user from server side to all users. I would like to get this new  feateure in order to compare the assignee with a REST API call to Gitlab that will verify that will relace the currentUser() function.

  • 0

    Similar idea:
    Using this as a way to compare parts of branch name to parts of jira fix version.


    branch name=release/PN2.1.8
    jira fixversion= Java PN 2.1.8
    this should be accepted as 2.1.8 is mentioned both places

    branch name=release/PN2.1.7
    jira fixversion= Java PN 2.1.8
    this should not be accepted, we are not doing this fix for 2.1.7.

    So comparing parts of branch name to parts of jira fix version, to ensure we are only allowing merge to specific versions. 

Please sign in to leave a comment.