CI isn't actually running (https://github.com/apache/arrow-adbc/actions/runs/11133252620)

The workflow is not valid. .github/workflows/rust.yml (Line: 45, Col: 3): Error calling workflow 'apache/arrow-adbc/.github/workflows/native-unix.yml@6bdf5d5'. The nested job 'go-no-cgo' is requesting 'id-token: write', but is only allowed 'id-token: none'. .github/workflows/rust.yml (Line: 45, Col: 3): Error calling workflow 'apache/arrow-adbc/.github/workflows/native-unix.yml@6bdf5d5'. The nested job 'go-conda' is requesting 'id-token: write', but is only allowed 'id-token: none'.

Thanks, now it seems Clippy is unhappy...

Are the failing tests known to be flaky?

FAILED python/adbc_driver_flightsql/tests/test_errors.py::test_query_error_bind - AssertionError: Regex pattern did not match.
 Regex: 'UNKNOWN:\\ \\[FlightSQL\\]\\ expected\\ error\\ \\(DoPut\\)'
 Input: 'UNKNOWN: [FlightSQL] EOF (Unknown; ExecuteQuery)'
FAILED python/adbc_driver_flightsql/tests/test_errors.py::test_stateless_prepared_statement - adbc_driver_manager.OperationalError: UNKNOWN: [FlightSQL] EOF (Unknown; ExecuteQuery)

Yes.

(TBH: why are we running those tests for Rust in the first place?)

Yes.

(TBH: why are we running those tests for Rust in the first place?)

It seems the native-unix workflow runs to produce some artifacts that are required to run the Rust unit tests. It would probably be better to just build the required lib(s) as part of the CI job (or even as part of the Rust build script). What do you think?

We could perhaps split the pipeline into a build and a test phase? (I believe we already sort of do this split within the pipeline itself)

IMO, let's merge this for now though.