Config format

[Starlight220]

So there are two options as to specifying project settings.

1. In the workflow YAML as an input/env. Any non-string types will have to be deserialized.
2. In a separate JSON file, which is loaded by ActionsKtLib. This possibly conflicts with the current mechanism for running locally (ActionsKtLib loads the inputs from a JSON file instead of from the environment variables. This gives greater freedom with types.

In the context of Inspector, these are the properties/options that will be passed:

root: String
baseUrl: String
versionScheme: String
latestVersion: String
ignoreFiles: Set<String>

Parsing either JSON or raw text isn't that problematic either way.

[Daltz333]

I think having it as a separate YAML would be more user intuitive and be more flexible in the long term. I don't see it as a good idea to have it defined in the workflow YAML. I am worried about the readability of exclusions/array content. Ideally it'd be similar to a python array of strings, where the strings are a path.

ignoreFiles: ["docs/software/wpilib-tools/shuffleboard/index.rst", "blah/blah.rst"]

[Starlight220]

About the readability/etc, this is the JSON file I'm using to run locally; a JSON config would look similar:

{
  "root": "../frc-docs/",
  "baseUrl": "https://raw.githubusercontent.com/wpilibsuite/allwpilib/",
  "versionScheme": "v\\d{4}\\.\\d\\.\\d(?:-beta-\\d)?|[0-9a-f]{40}",
  "latestVersion": "04e64db945afde667dae829d656392aec945e5c2",
  "ignoredFiles": ["source/docs/software/pathplanning/trajectory-tutorial/"]
}

Anything except ignoredFiles isn't a problem to pass via YAML. GitHub Actions doesn't allow passing arrays as inputs, so if we pass it through YAML it'll be a string with whatever form we chose (which will be deserialized by Inspector).

---

On second thought, I think that I'll modify ActionsKtLib to read inputs from the environment and the JSON file as a fallback anyway.

[Starlight220]

Having parameters be inputs in the workflow rather than in a JSON (or other config format) makes it impossible to work with PRs, as the main version would be used rather than the one in the PR branch.

So JSON it is.