Feature: More zizmor configuration locations

[Zeitsperre]

Pre-submission checks

• I am not reporting a bug (crash, false positive/negative, etc). These must be filed via the bug report template.
• I have looked through the open issues for a duplicate request.

What's the problem this feature will solve?

I just stumbled on this package the other day and really appreciate the work on this! The main problem I have is that the configuration location zizmor.yml is a bit too present for my liking.

Describe the solution you'd like

I would like to see a dotfile .zizmor.yml adopted by default (following other linting/checkers like .flake8, .pre-commit-config.yaml, .yamllint.yml, etc.) to make it easy to ignore this file in my build system (ignore= ".*").

Additional context

Given that this checker looks specifically at GitHub Workflows, I don't see any value in adding the configurations to a language-specific build file (namely pyproject.toml). Being able to drop this information when building a package is important.

[woodruffw]

Thanks for the request @Zeitsperre!

Two considerations:

• ICYMI, you can configure this: if you use the --config option, you can point zizmor at whatever filename you please. For example, zizmor --config .zizmor.yml should work, assuming .zizmor.yml exists.
• By default zizmor looks for both zizmor.yml and .github/zizmor.yml. The latter is inside of a "hidden" directory so that may be more to your taste.

I'm not entirely opposed to supporting .zizmor.yml as an automatically discovered file as well, but I'm hesitant to do so if either of the above is sufficient. My main hesitation there is that discovery rules are mostly irreversible public API commitments, so I'm trying to keep them to a minimum for now.

[Zeitsperre]

Hi @woodruffw, thanks for getting back to me so quickly!

I think for my purposes, I can get by with the --config option (and in fact, I've already set that up as a default in a project template). Personally, I tend to reserve the .github folder for things run by GitHub workflows or that affect the UX of the repo (like templates); I wouldn't think to look there for a pre-commit tooling configuration.

The convenience of being able to implicitly ignore the file in both a build-system (like flit for Python) and in my file browser is a "nice to have".

It isn't uncommon to have multiple (3) locations supported by default with one being a hidden top-level configuration file (e.g. flake8 or ruff) among the options, but perhaps this is more typical of Python projects.

In any case, for my purposes, things are fine as is. I totally understand not wanting to support too many standard locations.

All the best,

[woodruffw]

Hi @woodruffw, thanks for getting back to me so quickly!

Thank you too! I'm glad to hear --config is working for your current use case.

And got it -- I think in that case I'm going to leave things as they are for now, but I'll move this to a discussion item that other folks can chime in on. If there's consistent user interest in this outside of cases that --config can handle, then I'll look at adding it via your work in #321 🙂