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.
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
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:
Kind regards,Alexey
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?
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.
It looks like you're new here. Sign in or register to get started.
