Use PRs when importing engine sources #96
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@carlopi I wonder if you can take a look at the workflow changes? @maiadegraaf This change requires the Examples of PRs created by updated
|
This was referenced Mar 30, 2025
staticlibs
force-pushed
the
vendor_prs
branch
3 times, most recently
from
1d3164c to
3787cb3
Compare
Currently `Vendor.yml` workflow imports DuckDB engine sources and commits the changes to the `main` branch straight away. This PR changes this to import engine changes into a `vendoring` branch and create a PR on that branch. This PR triggers `ODBC.yml` tests runs. Additional job is added to `ODBC.yml` to merge the PRs on `vendoring` branch automatically after all tests are passed. When the import happens and the PR on `vendoring` branch is still open (when previous import did not pass the tests), then the imported changes are added to the `vendoring` branch and the PR is closed and re-opened to trigger the `ODBC.yml` workflow run. Non-default personal access token (`PAT_TOKEN` secret) must be used for creation or re-opening of the PR because the default token `GITHUB_TOKEN` is restricted to not trigger `pull_request` event. All other operations, besides the PR create/re-open, use the default token. Merge is done by rebasing all `vendoring` commits onto `main` branch, thus the history of the imports should look the same (linear) as it looks now with direct pushes. Testing: debugged this on a separate repo.
staticlibs
added a commit
to staticlibs/duckdb-java
that referenced
this pull request
May 5, 2025
This change brings in the logic for PR create/update on engine sources import the same way how it is done for ODBC in duckdb/duckdb-odbc#96.
staticlibs
added a commit
to duckdb/duckdb-java
that referenced
this pull request
May 5, 2025
This change brings in the logic for PR create/update on engine sources import the same way how it is done for ODBC in duckdb/duckdb-odbc#96.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently
Vendor.ymlworkflow imports DuckDB engine sources and commits the changes to themainbranch straight away.This PR changes this to import engine changes into a
vendoringbranch and create a PR on that branch. This PR triggersODBC.ymltests runs. Additional job is added toODBC.ymlto merge the PRs onvendoringbranch automatically after all tests are passed.When the import happens and the PR on
vendoringbranch is still open (when previous import did not pass the tests), then the imported changes are added to thevendoringbranch and the PR is closed and re-opened to trigger theODBC.ymlworkflow run.Non-default personal access token (
PAT_TOKENsecret) must be used for creation or re-opening of the PR because the default tokenGITHUB_TOKENis restricted to not triggerpull_requestevent. All other operations, besides the PR create/re-open, use the default token.Merge is done by rebasing all
vendoringcommits ontomainbranch, thus the history of the imports should look the same (linear) as it looks now with direct pushes.Testing: debugged this on a separate repo.