Support config files without extensions

[kehoecj]

Description

The current configuration file validator finder code recursively searches for files by file extension. Some types of configuration files do not typically include an extension such as ini files (see Ansible inventories). Options for supporting this:

Add a command line option to include extra files and metadata

Allow users to pass in a file or a string on the command line to include other files and their types. It might work something like this for the command line option:

validator --search-path /path/to/search --additional-file=inventory,ini --additional-file=myconfig,yaml

Or like this for the the file option

custom_config.yml example:

yaml:
  - myconfig,
  - myconfig2
ini:
  - inventory

CLI Command

validator --search-path=/path/to/search --additional-files-config=custom_config.yaml

Rewrite the finder code to detect each type of file (out of scope for https://github.com/Boeing/config-file-validator/labels/hacktoberfest)

This would be a much larger effort but would rewrite the finder to determine the type of each file based on content. The downside to this is that some config types are very similar (like TOML and INI) and some are supersets of other types (JSON and YAML)

[gokulav137]

Hi @kehoecj, I'm not familiar with this use case so wanted to understand if the --additional-file should be a filepath or filename.

I can work on this issue if this is clarified.

[LeslieLeung]

Can the finder code be more tolerant to unofficial extensions(such as .TOML)? I know that the spec says that the extension should be .toml, but some of the projects I am currently working on did use unofficial extensions.

[kehoecj]

Can the finder code be more tolerant to unofficial extensions(such as .TOML)? I know that the spec says that the extension should be .toml, but some of the projects I am currently working on did use unofficial extensions.

Hi @LeslieLeung - that's a good idea. For the example you provided we could ignore case when matching files to file types. I've also seen .INI pretty commonly used. Can anyone think of a reason not to support capitalized extensions?

[kehoecj]

@

Can the finder code be more tolerant to unofficial extensions(such as .TOML)? I know that the spec says that the extension should be .toml, but some of the projects I am currently working on did use unofficial extensions.

@LeslieLeung I created a separate issue to support capitalized extensions since it should be a really straightforward implementation

[ccoVeille]

This issue was old and I missed it when I opened #140 and #147

Maybe they should be addressed at the same time or being thought by having them in mind when working on this issue

[ccoVeille]

cc for @vogJust who works on #154