Multiple PRs

[melroy89]

I notice that if we merge unrelated changes to the main branch, each time the contributor workflow gets trigger.

That is of course by design, however there is an issue with this approach currently.

Each time this action runs, and a contribute change is detected, a new PR gets created. So in our case we sometimes get 3, 5 or more "Update contrib in README" pull requests of the same thing.

Meaning akhilmhdh/contributors-readme-action should detect first if the pull request already exist, and only create a new once if the PR is not present yet (or replace the existing PR). In all cases it should not keep creating new PRs.

[benelan]

Would the solution in #84 work for you?

[melroy89]

I guess. I can't easily test it since it's not yet part of your action / code.

However, I do believe a simple solution should be possible without the need to set additional flags. Since I think nobody want to have duplicate PRs like this by default.

[benelan]

However, I do believe a simple solution should be possible without the need to set additional flags. Since I think nobody want to have duplicate PRs like this by default.

Yeah, agreed. I'm not the maintainer though, and a minimal change that doesn't alter default behavior is more likely to be accepted.

I guess. I can't easily test it since it's not yet part of your action / code.

FWIW the workflow example I posted in the PR works as is because I changed it to use my fork and feature branch:

 uses: benelan/contributors-readme-action@no-commit-or-push # or pin commit: ...@74e2bf37858ca1bf098d142ab2f3853094f78cdd

So you can use that until the PR gets merged or the author comes up with a better solution.

[melroy89]

Yeah, agreed. I'm not the maintainer though, and a minimal change that doesn't alter default behavior is more likely to be accepted.

I always believe in fixing it correctly right way the correct way. Even if this alters the "default behavior". I do think @akhilmhdh would agree with this approach.

[akhilmhdh]

@melroy89 I am bit conflicted on the behavoir, so let me know which one is preferred or makes it more usable and spam free

1. Close all the previous open PR and raise it as new PR.
2. Push to the latest open PR.

My preference is first one because, the latest one could be quite below and nobody may notice the update.

[melroy89]

Last option is fine. The problem now we would like to get solved is it shouldn't open the same pr over and over again.

Even if the end result is the same, a new pr will be constantly created.

[melroy89]

Maybe my comment above was still not clear. Lets explain it even in more detail what the issue really is here.

I have a dedicated workflow file that triggers on main pushes, which is using your GitHub Action (contributors-readme-action): https://github.com/MbinOrg/mbin/blob/main/.github/workflows/contrib.yaml

If your GitHub Action detects that it need to do an update, it will trigger a pull request.

So far so good right?

However, if I do not merge your automated pull requests right away, so instead merge another pull request. You workflow is trigger again, and it will create yet another pull request. So your action is creating the same pull request over and over again.

So the real solution is the option you didn't mention:

3. Check if a PR request is already in place, and do not create a new PR at all (if the changes are the same)

[benelan]

@akhilmhdh could #84 be installed regardless of the additional work done on this issue? The PR also solves #83 and allows for a lot more customization that you may not want to build into this action.