Disable global pre-hook on project level

alexey_pelykh January 28, 2020

Is it possible to disable specific global pre-hook check on repository or project level? E.g. we have same settings for 99 projects and all newly-created ones, but there's 1 specific repository that falls out of line and does not needed those hooks.

1 answer

1 accepted

0 votes
Answer accepted
Robert Giddings [Adaptavist]
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 29, 2020

Hi @alexey_pelykh ,

This is an area of the UI we are looking to improve.

However if the pre-hook has a Condition field, then you could add the following to it, in the meantime:

repository.slug != "TEST"

This would then mean that the pre-hook would not run for that Repo. In this example, the "TEST" Repo.

Please let me know if this helps?

Kind regards,

Robert Giddings,

Adaptavist

alexey_pelykh January 29, 2020

Hi @Robert Giddings [Adaptavist]

Proposed approach can be a solution for custom pre-hooks e.g., yet not for "Naming standard enforcement" that has to be reimplemented as custom scripted one. Also, I'm not sure if I can add a custom property on repository to check in pre-hook.

In my case, vast majority of projects and repositories follow same guidelines, like naming of branches. Yet in case project needs to have a set of repositories that are mirrored from external sources (who naturally follow different rules), I want to configure at repository or project level what pre-hooks I want to Inherit or Disable. The workaround would be to just uncheck those at system level, but that requires elevated permissions that go beyond project ones. Another workaround would be to whitelist some bot user that does the repo sync to bypass the prehooks, yet that also means scripting.

Ideal solution for me seems to have following new features:

  1. Add "Mandatory = Yes/No" at system pre-hook level, to disallow inheritance disabling in some cases.
  2. List all inherited prehooks at project and then repository level with ability to "Disable" them if they are not "Mandatory"
  3. (Optional) Built-in prehooks should have "Condition" field, as you suggested. For "more power" reasons :)
  4. (Optional) Ability to set custom fields? I'm not even sure if Bitbucket Server has that concept.

Kind regards,
Alexey

Robert Giddings [Adaptavist]
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 29, 2020

Hi @alexey_pelykh ,

Thank you for your feedback. We are planning to look further into how we can improve this area of SR4BB for our customers.

Please can you expand on what you mean by "Ability to set custom fields?"? In what context do you mean?

Kind regards,

Robert Giddings,

Adaptavist

alexey_pelykh January 29, 2020

Hi @Robert Giddings [Adaptavist] ,

E.g. have a custom field on project or repository named "my_custom_reference_id" that can be set via REST API or script, that can be checked in pre-hook for example. That's a really long-shot request, if such request is unique - let's just ignore it. First three are much more value-generating, IMHO.

Kind regards,
Alexey

Robert Giddings [Adaptavist]
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 29, 2020

Hi @alexey_pelykh ,

Further to this discussion, would you be interested in participating in a customer interview with us, the ScriptRunner for Bitbucket team?

I'm the Product Manager for ScriptRunner for Bitbucket and we'd be interested to learn more about your usage of the product beyond the requirements you have described here.

Kind regards,

Robert Giddings,

Adaptavist

Robert Giddings [Adaptavist]
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 11, 2020

Hi @alexey_pelykh ,

By way of an update on the above discussion, we have now added a Condition field to the Project and Repository Naming Standards Enforcement listener and Branch and Tag Naming Standards Enforcement pre-hook to ScriptRunner for Bitbucket.

Both these additions should give you greater control over when those listeners and pre-hooks run.

Kind regards,

Robert Giddings,

Product Manager, ScriptRunner for Bitbucket

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events