MinIO tests might run on local disk #653
Description
What happens?
I noticed that ./build/release/test/unittest --test-config test/configs/minio.json doesn't seem to apply the test_env variables to the tests.
After some digging, it might be a regression from duckdb/duckdb@e7b1a6d where UpdateEnvironment populates test_env before the config file is read.
Here's a possible fix:
diff --git a/test/helpers/test_config.cpp b/test/helpers/test_config.cpp
index f1d8f8142c..ed674a6a02 100644
--- a/test/helpers/test_config.cpp
+++ b/test/helpers/test_config.cpp
@@ -467,7 +467,8 @@ vector<ConfigSetting> TestConfiguration::GetConfigSettings() {
}
string TestConfiguration::GetTestEnv(const string &key, const string &default_value) {
- if (test_env.empty() && options.find("test_env") != options.end()) {
+ if (!test_env_from_config_loaded && options.find("test_env") != options.end()) {
+ test_env_from_config_loaded = true;
auto entry = options["test_env"];
auto list_children = ListValue::GetChildren(entry);
for (const auto &value : list_children) {
diff --git a/test/include/test_config.hpp b/test/include/test_config.hpp
index aa4e8246f5..ade00efbaa 100644
--- a/test/include/test_config.hpp
+++ b/test/include/test_config.hpp
@@ -103,6 +103,7 @@ private:
string working_dir;
string test_uuid;
unordered_map<string, string> test_env;
+ bool test_env_from_config_loaded = false;
vector<unordered_set<string>> select_tag_sets;
vector<unordered_set<string>> skip_tag_sets;While this might be a bug in the duckdb codebase, I opened an issue in this repo because duckdb doesn't use test_env in any of its test config files.
Apologies in advance if this isn’t actually a bug and I’m just missing something in my local test setup!
To Reproduce
I could reproduce with the following test file:
# name: test/sql/repro.test
# description: XXX
# group: [sql]
require ducklake
test-env DUCKLAKE_CONNECTION __TEST_DIR__/{UUID}.db
test-env DATA_PATH __TEST_DIR__
query I
SELECT '${DATA_PATH}';
----
s3://mybucket
Then run:
$ ./build/release/test/unittest --test-config test/configs/minio.json "test/sql/repro.test"
Filters: test/sql/repro.test
[0/1] (0%): test/sql/repro.test
1. test/sql/repro.test:11
================================================================================
Wrong result in query! (test/sql/repro.test:11)!
================================================================================
SELECT 'duckdb_unittest_tempdir/51837';
================================================================================
Mismatch on row 1, column 'duckdb_unittest_tempdir/51837'(index 1)
duckdb_unittest_tempdir/51837 <> s3://mybucket
================================================================================
Expected result:
================================================================================
s3://mybucket
================================================================================
Actual result:
================================================================================
duckdb_unittest_tempdir/51837
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
unittest is a Catch v2.13.7 host application.
Run with -? for options
-------------------------------------------------------------------------------
test/sql/repro.test
-------------------------------------------------------------------------------
/home/utay/Code/duckdb/ducklake/duckdb/test/sqlite/test_sqllogictest.cpp:207
...............................................................................
test/sql/repro.test:11: FAILED:
explicitly with message:
0
[1/1] (100%): test/sql/repro.test
===============================================================================
test cases: 1 | 1 failed
assertions: 1 | 1 failed
OS:
Linux
DuckDB Version:
1.4.2
DuckLake Version:
0.3
DuckDB Client:
CLI
Hardware:
No response
Full Name:
Yannick Utard
Affiliation:
Altertable
What is the latest build you tested with? If possible, we recommend testing with the latest nightly build.
I have tested with a source build
Did you include all relevant data sets for reproducing the issue?
Yes
Did you include all code required to reproduce the issue?
- Yes, I have
Did you include all relevant configuration (e.g., CPU architecture, Python version, Linux distribution) to reproduce the issue?
- Yes, I have