Use the same branch instead of opening multiple PRs

[ChipWolf]

Reason/Context

Currently, every time the workflow runs, it opens a new PR on all of our repos. The behaviour should be similar to most other tools where the same branch is reused/force-pushed to.

[derberg]

Hey, it should rather be optional. For us for example it is ok as we remove branch after merging a PR

[ChipWolf]

Indeed, but I don't believe any user needs multiple PRs; so, a static branch name should be sufficient, no? @derberg

[derberg]

but I don't believe any user needs multiple PRs

Sorry but I don't fully understand this. Can you share an example? Do you mean a situation that some workflow was updated, PRs are created in some repos, and before they are merged, another global workflow is updated and therefore another PRs are created in some repos? and you'd like to just commit to existing branches instead of creating new branches and new PRs?

[stockf]

I think that's exactly what he means and I would second that.

[derberg]

Makes sense. You can easily figure out that there is already a PR from a bot that updates workflows. You would just need to checkout the branch and update it and skip rest of the steps like PR creation.

Is it ofter happing to you guys? not for us at all as we are auto merging those

[ReenigneArcher]

I would also like this feature. I use a strategy matrix for this action (see #39), and even with using an automerge action it would be nice to have a cleaner history. Adding concurrency to the automerge action seems like a decent approach.

This is a similar action that creates a single PR. https://github.com/BetaHuhn/repo-file-sync-action

The disadvantage of that one being that you have to manually specify each repo you want to sync to and it requires a separate config file.

[derberg]

This is how branch names are generated: https://github.com/derberg/copy-files-to-other-repositories/blob/2ce7d45669222bbf63d390104b7af251d7318347/lib/utils.js#L214

We can add some option, but I don't think by default, that would check, if there is a branch that starts with bot/update-global-workflow or bot/manual-update-global-workflow - then just reuse it.

Would you folks be happy with such an approach?

[ReenigneArcher]

I think you would need to check if the branch is also the same, in the event a user is making commits to multiple branches.

Or just add an input so the new branch name can be explicitly specified. If the value is blank default to the method above.

P.S. This could also solve this issue. If you have branch protection rules that require the branches to be up to date, automerge doesn't work except on the first PR.

[derberg]

regarding out of date branch, you need to add another workflow that always autoupdates branches. This is how we do it at AsyncAPI -> https://github.com/asyncapi/.github/blob/master/.github/workflows/autoupdate.yml

[derberg]

fyi I start working on that

will take the same approach as sticky comment action -> https://github.com/marocchino/sticky-pull-request-comment/blob/main/src/comment.ts

dummy but works and battle proved

when the PR is created by this action, it will have a hidden identifier like <!-- Manage Files In Multiple Repos Action ${id} -->

so action before creating a new branch, will just check if there are other PRs from the action and checkout the existing branch and push to it

${id} is for users that want to make sure that some changes in workflows do not go in a single PR and are still kept separately

---

This new approach will be default and new major will be released

🤞🏼 all works as planned

[ReenigneArcher]

@derberg You could just add an input for the branch name, then you don't need to parse the PR bodies and it will save api requests.

[derberg]

@ReenigneArcher but the branch name is not predictable, it is generated to make sure it is unique. You mean you want to have an option to override this default branch name generation?

[ReenigneArcher]

but the branch name is not predictable, it is generated to make sure it is unique. You mean you want to have an option to override this default branch name generation?

I know that it's generated right now, but if you're moving to make using the same branch the default behavior, you don't need a generated branch name. Just allow the user to specify the branch name.

If it doesn't exist, create it. If it does exist, checkout the branch.

Leave it up to the user to make sure it's unique for their needs. For example

with:
  branch_name: "ci: update global workflows"

Personally, I have close to 25 repos, some with close to 50 open PRs. And I run this as a strategry matrix, with 6 jobs that happen one after another. If you're going to parse every open PR body to see if there's a comment in the body, I won't be able to use this action anymore as that will be a significant amount of api requests. At least 300 requests for a repo with 50 open PRs. 25 repos with 50 PRs each would be 7500 api requests. While I don't have that many open PRs altogether, I'm sure many people using this action do have that many. Anyway, that exceeds the hourly api limit, which I believe is 5000.

[derberg]

@ReenigneArcher no worries. I liked your idea better. Simple and during implementation I could not spot any edge cases that would cause some issues with the action.

PR ready https://github.com/derberg/manage-files-in-multiple-repositories/pull/50 Will release soon and use in my project. In test org all was good. Now time for testing in production 😆