chore: Update dev branches with merge

[lantoli]

Description

Update dev branches with merge. Don't use a PR as it will squash the commits and will cause the same conflicts to appear again and again.

It uses merge instead of rebase so history is not altered and changes can be reverted if necessary.

skip-docs-notification label is not needed any more as we don't create a PR here.

Link to any related issue(s): CLOUDP-329420

Type of change:

• Bug fix (non-breaking change which fixes an issue). Please, add the "bug" label to the PR.
• New feature (non-breaking change which adds functionality). Please, add the "enhancement" label to the PR. A migration guide must be created or updated if the new feature will go in a major version.
• Breaking change (fix or feature that would cause existing functionality to not work as expected). Please, add the "breaking change" label to the PR. A migration guide must be created or updated.
• This change requires a documentation update
• Documentation fix/enhancement

Required Checklist:

• I have signed the MongoDB CLA
• I have read the contributing guides
• I have checked that this change does not generate any credentials and that they are NOT accidentally logged anywhere.
• I have added tests that prove my fix is effective or that my feature works per HashiCorp requirements
• I have added any necessary documentation (if appropriate)
• I have run make fmt and formatted my code
• If changes include deprecations or removals I have added appropriate changelog entries.
• If changes include removal or addition of 3rd party GitHub actions, I updated our internal document. Reach out to the APIx Integration slack channel to get access to the internal document.

Further comments

[Copilot]

Pull Request Overview

This PR replaces the previous rebase-based dev-branch updates with a merge-based workflow to avoid repeat conflicts caused by squashed commits. Key changes include removing the rebase inputs, adding a commit-count check and an automated git merge, and replacing the PR creation step with direct pushes and Slack notifications.

Comments suppressed due to low confidence (2)

.github/workflows/update-dev-branches.yml:54

• To ensure you're counting up-to-date master commits, run git fetch origin master (or a full fetch) before computing commits_to_merge, otherwise origin/master may be stale from earlier steps.

 commits_to_merge=$(git rev-list --count origin/${{ matrix.branch }}..origin/master) 

.github/workflows/update-dev-branches.yml:64

• [nitpick] Consider moving these detailed manual resolution steps to an external documentation page and linking to it here, so the workflow file stays concise and easier to maintain.

 echo "ERROR: Merge conflicts detected. Manual intervention required:" 

[maastha]

LGTM

[EspenAlbert]

Would it be cleaner to have this in a separate script?

[lantoli]

at the moment I think it's better here because it also need to coordinate with the push step, so it's easier to see what's going on. If it get more complicated I agree to move it

[EspenAlbert]

Should this be before the Push updated branch?

[lantoli]

@EspenAlbert as this is to do a merge without PR, I think it's better to avoid to to this manually as much as we can. So if the merge doesn't have conflicts, we push the changes, so later the checks can be fixed easily in a PR.

however if we don't push the changes, somebody has to manually fix it and merge, without a PR.

[EspenAlbert]

Sounds good. I think the best way is to go ahead with this approach, and then later we can revert/change based on experience 👍

[lantoli]

agreed, thanks