Add support for separate voting.yml

[ben-pr-p]

We're evaluating using git-democracy to collaboratively make internal company decisions, but our problem is that we have different types of decisions that require different thresholds, and so we'll need many different voting.ymls and voters.ymls.

The way we're approaching organizing our documents, we could do it by directory - if a pull request has changes that modify the contents of a directory, the voting rules for that directory's voting.yml (or a parent directory, recursively) are used. For standard code applications, this may also work well for monorepos, etc.

If only one root voting.yml is present, that's what's used.

If the pull request has multiple changes in different folders which include different voting.ymls, we go up to the next highest and maybe root voting.yml.

A solution that would also work for us is to have multiple voting.ymls, like:

bylaws-change.voting.yml
new-project.voting.yml
...

and have some way of indicating which process was appropriate in a metadata convention on the PR.

If you're interested in having one of both of these as part of git-democracy, that'd be awesome!

If not, no worries - we'll fork and implement ourselves. Just wanted to check to see if you wanted :)

[myyk]

I'm definitely interested in being able to support monorepos with this projects. I think the way I would intuitively think of the config working is a little different though. I'm wondering if this might work for you too.

Alternative solution: The deepest voting.yml found would be the one used for that section of code. Also if there's no voting.yml covering a section of code, it won't use one. (I can draw out an example later if that idea isn't clear.)

If one of these approaches were added, then it would potentially need to present multiple voting comments or a multi-vote single-comment. This might be pretty confusing if not done well. What do you think this experience should look like?

Another option that might work would be to add a configuration for this action that lets you specify where the config is, then for the user if they have a workflows per action, they can just ignore the action if there's no changes in that directory or use the action on the directory. (I think this would still need an answer for multi-votes though.) This usage would more closely match how my company configures other github actions in their monorepo.

If you're interested in having one of both of these as part of git-democracy, that'd be awesome!

I'm interested, just not sure how to solve it in an intuitive to use way.

[bchrobot]

Another option that might work would be to add a configuration for this action that lets you specify where the config is, then for the user if they have a workflows per action, they can just ignore the action if there's no changes in that directory or use the action on the directory.

This seems like the best general solution to me!

It could look something like:

name: 'Voting'
on:
  pull_request_target:
    types: [opened, synchronize, reopened, closed]

jobs:
  changes:
    runs-on: ubuntu-latest
    outputs:
      core-operation: ${{ steps.changes.outputs.core-operation }}
      committee-charters: ${{ steps.changes.outputs.committee-charters }}
    steps:
      - uses: dorny/paths-filter@v2
        id: changes
        with:
          filters: |
            core-operation:
              - 'core-operation/**'
            committee-charters
              - 'committee-charters/**'

  democracy:
    runs-on: ubuntu-latest
    needs: changes
    strategy:
      matrix:
        include:
          - documentSet: core-operation
            configDir: "./config/core-operation"
          - documentSet: committee-charters
            configDir: "./config/committee-charters"
    if: ${{needs.changes.outputs[matrix.documentSet]}} == 'true'
    name: Vote on ${{ matrix.documentSet }}
    steps:
      - uses: actions/checkout@v2
      - name: Evaluate vote
        uses: myyk/git-democracy@v1
        with:
          configDir: ${{ matrix.configDir }}

I'm not sure if if: ${{needs.changes.outputs[matrix.documentSet]}} == 'true' would work, but it's not too much of a lift to specify each job individually.

(I think this would still need an answer for multi-votes though.)

If the above were used there would be a voting result per job. If a PR touches multiple jobs then some path-based votes (and GH checks) could fail while others passed. It would then be on the PR owner to figure out how to address. Either reduce the scope of the changes, or address results from each path-based vote configuration.

[myyk]

This idea sounds good to me. I'm going to say this proposal is accepted. I think that's a reasonable approach to take. If you made a PR that supports this with some documentation and an example of a branch using the change, I would accept it.

It would be a good addition. The idea of two transactionally accepted changes together is an interesting voting concept too. I like that this supports that.

[myyk]

With the now released v2 and the comment by bchrobot above, I think multi-config repos are now a thing. This is untested, if anyone want so write an example, that would be great. Would love to add this to the README.md as well.

[myyk]

I'm going to close this as I think it's implemented.