Created a GitHub Action workflow that creates a PR to sync main-to-dev

[chanmosq]

Change summary

This introduces a new workflow that creates a PR to sync main-to-dev. It is triggered whenever there is a merge to main. If there are multiple merges to main, only one sync PR is automatically created.

This workflow the Sync Branches GitHub Action.

Testing

I've tested the workflow in my own fork. Here are the test cases:

Test 1

Test with few changes in docs/ (commit 1a4d75a). The commit came from upstream/main, and was committed after the commit, WK 5 main-to-dev-sync (d6456ee). Therefore, this commit will be branc new to origin/development

1. Run the following commands to cherry-pick a new commit into main

git switch -c main
git cherry-pick 1a4d75a
git push origin main

2. Create a PR: Testing auto-pr-main-to-dev workflow: Few changes in docs/  chanmosq/o3de.org#6
3. Merge the PR.
4. A few minutes later, observe how this sync PR was automatically created: sync: main to development chanmosq/o3de.org#7
   **Note: The generated sync PR in "Test 1" shows numerous commits to merge into development. This is not expected, given that synced development to this point when completing the steps in "Setting up a Test Environment". The only commit expected was 1a4d75a. However, in "Test 2", the generated sync PR has only one commit, as expected.

Test 2

Test with more changes in docs/ (commit 397fca0). We follow the same steps as Test 1, but with another commit. Again, merging the PR to main , led to the automatic creation of a sync PR: chanmosq#8

Test 3

Test with multiple pushes to main (commits 29ce2f5, 29916f8, and 25f0bae). This did not trigger the workflow to create multiple sync PRs - it only created one sync PR, which updated whenever a new commit was pushed to main: chanmosq#9

git switch -c main

# A push to main
git cherry-pick 29ce2f5
git push origin main

# Another push to main
git cherry-pick 29916f8
git push origin main

# One more, pushed after the auto PR was created
git cherry-pick 25f0bae
git push origin main

As Test 3 shows, there is no need to worry about multiple auto sync PRs being created.

Submission Checklist:

• Descriptive active voice - Do descriptive sentences have a clear subject and action verb?
• Answer the question at hand - Does the documentation answer a what, why, how, or where type of question?
• Consistency - Does the content consistently follow the Style Guide?
• Help the user - Does the documentation show the user something meaningful?

[willihay]

Nice! Let's try it! Will reviewers get automatically added per our current CODEOWNERS rules?

[willihay]

I suppose this means that every time a PR is merged in main, we can expect another PR to be created to merge it to dev. This could get tedious if it happens with every PR. I wonder if this workflow could be scheduled to run 1x per day or week.

[chanmosq]

@willihay I'm not sure if the codeowners rules will apply to the auto-created PR, we'll find out when we use it. Otherwise, the GitHub Action also accepts the parameters, REVIEWERS and TEAM_REVIEWERS.
Actually, I might update this now to be sig-docs-community-maintainers or the broader Maintainers team.

[chanmosq]

I suppose this means that every time a PR is merged in main, we can expect another PR to be created to merge it to dev. This could get tedious if it happens with every PR. I wonder if this workflow could be scheduled to run 1x per day or week.

The behavior I observed is when a PR first merges to main, an auto sync PR is created from main to development. Holding off on merging that first auto sync PR, when more PRs merge to main, the commits appear in the first auto sync PR, rather than auto-create new ones. (Check out test case 3)

[willihay]

I suppose this means that every time a PR is merged in main, we can expect another PR to be created to merge it to dev. This could get tedious if it happens with every PR. I wonder if this workflow could be scheduled to run 1x per day or week.

The behavior I observed is when a PR first merges to main, an auto sync PR is created from main to development. Holding off on merging that first auto sync PR, when more PRs merge to main, the commits appear in the first auto sync PR, rather than auto-create new ones. (Check out test case 3)

Oh, got it! So commits from merged PRs will just keep stacking into an existing sync PR instead of creating a new one? That sounds perfect. I suppose the workflow must look for existing sync PRs that it had already created.