Skip to content

feat(): enable auto-merge on bump PRs#28

Merged
bengeois merged 2 commits into
bengeois:mainfrom
Gudsfile:feat/auto-merge-bump-prs
Jun 30, 2026
Merged

feat(): enable auto-merge on bump PRs#28
bengeois merged 2 commits into
bengeois:mainfrom
Gudsfile:feat/auto-merge-bump-prs

Conversation

@Gudsfile

@Gudsfile Gudsfile commented Jun 18, 2026

Copy link
Copy Markdown
Collaborator

Follows up on #25.

Once the build matrix passes on a bump PR, auto-merge triggers automatically, no need to merge manually.

How it works

After peter-evans/create-pull-request opens a new bump/duckdb-X.Y.Z PR, the workflow calls gh pr merge --auto --merge on it. The merge happens only when all required status checks pass. If any job fails (e.g. a Python version no longer supported by DuckDB), the PR stays open for review.

Setup required

In addition to the setup described in #25:

  1. Settings > General > enable Allow auto-merge
  2. Branch protection on main: configure Build DuckDB (the package-duckdb matrix jobs) as required status checks

Open question

Auto-merge is intentionally gated on the build matrix only. However, until PYTHON_VERSIONS is managed automatically (detecting which Python versions DuckDB ships wheels for and which Lambda supports), a passing build does not guarantee complete coverage, it only validates the versions currently in the matrix.

My approach would be to: keep "Require approvals" enabled on main so a reviewer can check PYTHON_VERSIONS before merging. Auto-merge would still remove the need to click merge manually, but would wait for the approval first. Or check Python versions in the CI #29.

Enable auto-merge (squash) on newly created bump/duckdb-* PRs so they
merge automatically once all required status checks pass. Skipped on
PR updates (idempotent runs) to avoid redundant gh calls.

Requires repository setting "Allow auto-merge" and branch protection
on main with required status checks configured.
@Gudsfile Gudsfile force-pushed the feat/auto-merge-bump-prs branch from 12f3688 to 322672d Compare June 21, 2026 15:56
@Gudsfile Gudsfile marked this pull request as ready for review June 21, 2026 15:58
@Gudsfile Gudsfile requested a review from bengeois as a code owner June 21, 2026 15:58

@bengeois bengeois left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this PR, really helpful!

I was going through the configuration and ran into an issue with the required status checks: the matrix jobs each generate a separate check (Build DuckDB (3.10, x86_64), Build DuckDB (3.11, arm64), etc.), so you'd have to add every combination individually in the branch protection rule, and update it each time PYTHON_VERSIONS changes.

The standard fix is to add a small summary job that depends on the whole matrix and acts as a single gate:

all-builds-passed:
  name: All builds passed
  needs: [package-duckdb]
  if: always()
  runs-on: ubuntu-latest
  steps:
    - name: Check matrix result
      run: |
        if [ "${{ needs.package-duckdb.result }}" != "success" ]; then
          exit 1
        fi

I would then only need to configure All builds passed as the required status check, one stable entry, regardless of how many matrix combinations exist.

What do you think ? Can you include this in your PR if you agree ?

@Gudsfile

Copy link
Copy Markdown
Collaborator Author

What do you think ? Can you include this in your PR if you agree ?

Good point, it’s been added!

@Gudsfile Gudsfile requested a review from bengeois June 23, 2026 15:00
@Gudsfile

Copy link
Copy Markdown
Collaborator Author

Hi @bengeois, since #29 has been merged you could now add check-python-versions to the required status check and maybe remove the approval requirements.

@bengeois

Copy link
Copy Markdown
Owner

Setup completed ✅

Thanks @Gudsfile 🙌

@bengeois bengeois merged commit a671419 into bengeois:main Jun 30, 2026
14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants