Cannot use local file

[bduffey-pe]

Hello! Our team recently came across this workflow and wants to implement it in our organization. Unfortunately, it looks like it pulls the config file from the repo always instead of locally during the action.

We have many devs and constantly are rolling devs on and off the project so it would be not a great solution for us to maintain every single repo we have with this config file. Instead, we were hoping to store this file somewhere else and then pull it into the local repo at .github/auto_request_review.yml prior to running this step.

Is it possible to do this today and we missed it or would it be possible to add this option, as not only would this make our lives much easier, but it would also help solve issues like #12 where the config file exists in the PR but not yet the repo. Thank you!

[necojackarc]

@bduffey-pe Thanks for raising the issue and pull request 👍

I'm not quite sure what you mean by "local" yet. By looking at the logic in your PR #77, perhaps, you'd like to use the configuration file that in the target branch, not in the source branch?

I can't remember what context.ref returns exactly but I think it returns:

The fully-formed ref of the branch or tag that triggered the workflow run

ref: https://docs.github.com/en/actions/learn-github-actions/contexts

So if you use pull_request, it should return the target branch whereas pull_request_event returns the source branch. I'm not 100% sure though.

Which event do you use?

[bduffey-pe]

Hey @necojackarc , thanks for the reply! I agree that my usage of local is ambiguous. In this case, local means local to this script executing (as in within the container that is running when this script executes in GitHub Actions). For our team specifically, we have one reviewer yaml file that has many developers (10+) and many groups (currently 9), and storing this individually in each of our many repos (15+) would be a nightmare to maintain.

So, we store this file elsewhere (for us that's Azure Storage but it could just as easily be S3 or Google Drive or any place where a file can be downloaded from) and just wget it immediately prior to running this script. So the file is never in our repo at all and I don't want this script to look for it there.

For others, whether they choose to keep the file externally or not, if they shallow clone their PR branch before the script runs, it will pick up the latest version of this file, which means it will work for brand new PRs as well where the file is in the PR and not in the repo yet. That was my reference to it solving #12 .

Since I made it a config that by default is false (behavior today) it seemed like a nice way to work for both my (and hopefully others' needs) as well as continue to work for you and anyone relying on its functionality today. Does that help explain it better?

[necojackarc]

we store this file elsewhere (for us that's Azure Storage but it could just as easily be S3 or Google Drive or any place where a file can be downloaded from) and just wget it immediately prior to running this script. So the file is never in our repo at all and I don't want this script to look for it there.

This is quite an interesting use case!

Ideally speaking, perhaps, you may want to add the direct URL to the stored file such as in S3 with the necessary credentials so that the Action can directly download the config, but I feel this is a good middle ground as it's simple enough.

I'll give some feedback on your pull request 👍

[necojackarc]

#77 has resolved this issue. I'm going to make a new release 👍