Feature Request: custom default values

[josephperrott]

I think it would be really valuable to be able to provide a default value for attributes in the groups throughout a config file.

My thinking is that it could work something like this:

defaults:
  group: 
    reviews:
      author_value: 1
      request: 15

This would then be used as the value if any pullapprove group doesn't provide a value for an attribute.

I think this would be valuable in preventing the need to repeat the same attribute throughout the config file.

[davegaeddert]

What would be the primary advantages of this over YAML anchors/aliases? Is deep-merging (example) the primary reason you're thinking about this?

[davegaeddert]

Hey @josephperrott -- I'm sure you're plenty busy, just wanted to poke you on this one and see if you had any other insight to share?

[josephperrott]

I think the main advantage provided over anchors/aliases is not having to remember to use it. Its completely reasonable to use anchors/aliases it just isn't super intuitive/apparent at first glance for someone who isn't super familiar with YAML.

[davegaeddert]

Totally agree. I think I will just leave this issue open for now. Reusing config is a bit of an advanced use case, and in my opinion makes it hard to track down where values come from anyway, so I'm ok with it being a little bit difficult for now.

There are some related ideas that are being kicked around in terms of a more fine-grained extends feature on the group level. Not a fleshed out idea at this point, but potentially being able to more specifically use review group concepts across your own organization or from others. Along the lines of how GitHub Actions work.

groups:
  dependencies:
    # leverage a standard someone else has established
    extends: dropseed/pullapprove-best-practices:dependencies@1.0.0
    # and apply it to us
    users: [davegaeddert]

# could also reference a url or something in this local file if you want (the above is just a shorthand for github),
# `extends: "https://... :key1.key2"`
# `extends: ":meta.group_defaults.dependencies"`

(this is as far as the idea has been thought out! just sharing it to help clarify for myself -- no idea if we'll actually go there)

Another thing that would bring this back into play would be if we allowed configs to be written in other formats, like TOML, where we can't rely on YAML features at all.

Long story short, I want to leave this open for the time being and see if other features have an impact.