Consider .toml configuration?

[jenstroeger]

I understand that the Action is written in Node/JavaScript and as such it’s convenient to default to JS/JSON for configuration, e.g. a commitlint.rules.js file.

However, when used in a Python repository this is not really desirable because there the convention is to configure such projects using a pyproject.toml file.

There’s a node package which offers some toml support and I think it would be very useful to add toml configuration support to this Action: by default, read config and rules from JS/JSON files, or an Action yaml option to read config and rules from a toml file, e.g.

    steps:
      - uses: actions/checkout@v2
      - uses: CondeNast/conventional-pull-request-action@main
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          commitlintRulesPath: "./pyproject.toml"
          commitlintRulesFormat: "toml"
          commitTitleMatch: "true"

[ferdnyc]

(I'll butt in, because sure why not?)

I've thought about this some, and I have to say I don't think I agree.

However, when used in a Python repository this is not really desirable because there the convention is to configure such projects using a pyproject.toml file.

But you're not configuring the project here, you're configuring the repository. Specifically, the CI job that runs on that repository, only in a GitHub environment, only when Actions is available and enabled.

Your workflow file (the only place this is used from) is already written in YAML. It's not like you haven't already departed the Python ecosystem. Which is OK, because nothing about what's happening here has the slightest bit to do with Python. It's a GitHub Actions workflow configuration.

Defining the configuration in Python would only make it less accessible to the workflow, while adding nothing to the Python project because it's a configuration that is only active when a JavaScript Action running in a YAML-configured CI container is configured on a (specifically) GitHub code repo.

(And that repo can contain anything, in any language, because git commits are completely content-agnostic. The process is the same whether you're checking in Node modules, website SVG images, Python packages, Ruby gems, or Befunge... whatever collective units you use to describe Befunge programs, I don't know. Befungi?)

...That's my take, anyway.

[jenstroeger]

Thank you @ferdnyc! I see your point, and it makes sense.

I opened this issue because my Python package cookiecutter repo became a little too crowded with various configuration files, and this one felt like the most alien of the bunch…