Handle non-group related hooks when using groups

[FredrikBakken]

I am currently looking into the groups setup in prek (nice feature btw 🥳) and find myself in a situation where I'd want to run all hooks that are not mapped to a specific group and also the hooks specific to a declared group.

As an example, I have the following:

[[repos]]
repo = "builtin"
hooks = [
    { id = "trailing-whitespace" },
    { id = "check-added-large-files" },
    { id = "check-case-conflict" },
    { id = "end-of-file-fixer" },
    { id = "fix-byte-order-marker" },
    { id = "forbid-new-submodules" },
    { id = "check-toml" },
    { id = "mixed-line-ending" },
    { id = "check-symlinks" },
    { id = "check-merge-conflict" },
    { id = "detect-private-key" },
    { id = "no-commit-to-branch", args = ["--branch", "main"] },
    { id = "check-shebang-scripts-are-executable" },
    { id = "check-executables-have-shebangs" },
]

[[repos]]
repo = "https://github.com/<org>/<repo>"
rev = "v1.4.2"
hooks = [
    {
        id = "helm-build-dependencies",
        require_serial = true,
        stages = ["manual"],
        groups = ["ci"],
    },
    {
        id = "helm-lint",
        stages = ["manual"],
        groups = ["ci"],
    },
]

In my CI pipeline, I'd love to be able to define something like:

prek run --all-files --group ci --all-non-groups

Which would the run all the builtin hooks defined and also the hooks in the ci group, without having to define that all the hooks in the builtin repo are in a declared group. Another alternative could be to have builtin become a "protected" group name, which all the hooks in the builtin repo are added to by default.

[j178]

Thanks for suggestion, I added two special groups @ungrouped and @builtin in #2617

[j178]

Update: I’ve decided to remove @builtin for now in #2628. It is not useful enough to justify a special selector, and unlike @ungrouped, it does not directly express group membership; it is effectively a repository selector. The @ namespace remains reserved, so we can revisit this if a clearer use case emerges.