You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The tool aims to keep the configuration file structure in sync with the raw Bitbucket API structure. This may indeed simplify the tool, but also makes the configuration files complex and hard to read.
The proposal is to implement a mechanism that allows preprocessing the configuration file with a set of "parse transform-like" functions that could map a user-friendly structure to the raw format used internally in later stages.
The transforms shall also document the Yaml format they accept.
This would allow things like:
Using short names instead of long hook keys (e.g. http-get-post-receive-hook instead of de.aeffle.stash.plugin.stash-http-get-post-receive-hook:http-get-post-receive-hook).
Replace the admittedly terrible API of some plugin with something more user friendly.
Allow the same configuration file to transform to different raw representations based on Bitbucket version when there are API changes.
Group together settings logically instead of splitting them by plugin-boundary (I'm looking at you pr{{-restrictions}}, wz-branch-reviewers and wz-workflow elements).
The text was updated successfully, but these errors were encountered:
The tool aims to keep the configuration file structure in sync with the raw Bitbucket API structure. This may indeed simplify the tool, but also makes the configuration files complex and hard to read.
The proposal is to implement a mechanism that allows preprocessing the configuration file with a set of "parse transform-like" functions that could map a user-friendly structure to the raw format used internally in later stages.
The transforms shall also document the Yaml format they accept.
This would allow things like:
The text was updated successfully, but these errors were encountered: