846 Commits (GH-Actions)

Author	SHA1	Message	Date
René Cannaò	4b53979c07	Merge pull request #5793 from sysown/fix/ghcr-pull-retry ... fix(ci): retry transient GHCR login + pull failures	1 day ago
Rene Cannao	fd6167306c	fix(ci): start the proxysql cluster on mariadb10-galera-g5 ... mariadb10-galera-g5 is the TAP group that runs test_cluster1-t, which exercises ProxySQL's config-sync mechanism across a 10-node ProxySQL cluster (primary on 6032 + 9 satellites on 26001-26009). The test opens admin connections to all 10 endpoints and asserts that runtime checksums converge across them. The reusable workflow as it stood passed 'SKIP_CLUSTER_START=1' to both ensure-infras.bash and run-tests-isolated.bash. That env value makes cluster_init.bash / cluster_start.bash skip the spawn of the 9 satellite ProxySQL instances, so when the test reaches its first connect to port 26001 it sees nothing listening: wait_for_proxysql_cluster: 9/10 endpoint(s) did not respond within 60s not ready: proxysql:26001 last error: Can't connect to server on 'proxysql' (115) not ready: proxysql:26002 ... The cryptic 'errno 115 / EINPROGRESS' that test_cluster1-t was hitting before sysown/proxysql#5782 was the same root cause; that PR added a readiness probe to the test which turned the silent failure into the clear diagnostic shown above. The other galera-g* workflows also set SKIP_CLUSTER_START=1, but they do not run test_cluster1-t and don't need the satellite cluster. Only g5 needs the cluster, so the smallest correct change is to drop the two SKIP_CLUSTER_START=1 exports from ci-mariadb10-galera-g5.yml. This makes the workflow consistent with the corresponding mysql84-g5, mysql84-gr-g5, legacy-g5 etc. workflows, none of which set the var.	6 days ago
Rene Cannao	149d0cfba5	fix(ci): retry transient GHCR login + pull failures ... Observed failure (PR sysown/proxysql#5778, CI-mysql84-g9 run 25791456553, and earlier on CI-mariadb10-galera-g8 run 25782877144): Error response from daemon: Get "https://ghcr.io/v2/": net/http: request canceled (Client.Timeout exceeded while awaiting headers) ##[error]Process completed with exit code 1. The failure happens at the GHCR auth-token step inside `docker/login-action@v3` (or sometimes inside the subsequent `docker pull`). A single network blip against ghcr.io reds the whole TAP group, even though the test infrastructure itself is fine. Re-running the workflow then succeeds. Merge the previous two-step `Log in to GHCR` + `Pull CI base image` into one bash step wrapped in a 5-attempt retry loop with linear backoff (10s, 20s, 30s, 40s). On the first success, exit cleanly; on five consecutive failures, exit non-zero so the surfaced error is still loud rather than silently masking a real outage. Applied to all 41 reusable test workflows that pull `ghcr.io/sysown/proxysql-ci-base:latest`.	6 days ago
Rene Cannao	62123bd370	feat(ci): add reusable workflows for CI-mariadb10-galera-g[1-9] test groups	2 weeks ago
Rene Cannao	ce694ba2da	fix(ci): remove SKIP_CLUSTER_START=1 from mysql84-gr-g5 workflow ... The mysql84-gr-g5 group runs test_cluster1-t which requires a multi-node ProxySQL cluster (ports 6032, 26001-26009). With SKIP_CLUSTER_START=1 only the primary ProxySQL node starts, causing test_cluster1-t to fail with 'Can't connect to server on proxysql (115)'.	2 weeks ago
Rene Cannao	ad296936ae	feat(ci): add reusable workflows for CI-mysql84-gr-g[1-9] test groups	2 weeks ago
Rene Cannao	1d08f312d9	fix(ci): add GHCR authentication before docker pull ... GHCR packages are private by default. Add docker/login-action step to authenticate with GITHUB_TOKEN before pulling proxysql-ci-base in all 23 reusable workflows.	2 weeks ago
Rene Cannao	4d4bb823c8	perf(ci): pull pre-built proxysql-ci-base from GHCR instead of building ... Replace "docker build" of proxysql-ci-base in all 23 reusable workflows with "docker pull" from ghcr.io/sysown/proxysql-ci-base:latest. Eliminates apt-get update/install on every CI run, avoiding transient Ubuntu mirror sync failures and saving ~60s per job.	2 weeks ago
Rene Cannao	685d05209c	feat(ci): add reusable workflows for split test groups g6-g9 ... Companion to v3.0 PR #5748. Adds ci-legacy-g{6,7,8,9} and ci-mysql84-g{6,7,8,9} reusable workflows on GH-Actions branch.	2 weeks ago
Rene Cannao	aa465bbc54	fix(ci): rename set_parser_algorithm=3 workflow to avoid Docker network issue	2 weeks ago
Rene Cannao	a4ff1ea80d	ci: add ci-set_parser_algorithm=3-g1 reusable workflow ... Add the reusable workflow for the set_parser_algorithm=3-g1 test group, cut from ci-legacy-g4.yml. This is the GH-Actions counterpart to the CI-set_parser_algorithm=3-g1 caller that already exists on v3.0. The group runs SET-related TAP tests with ParserSQL-based SET parser enabled (set_parser_algorithm=3) for both MySQL and PostgreSQL protocols.	2 weeks ago
Rene Cannao	76434aca35	ci: reduce API polling interval from 5s to 20s ... The CI-trigger workflow polls `gh run list` in a loop every 5 seconds to find the CI-builds run ID. With 20+ concurrent CI workflows, this generates ~480 API calls/minute, exhausting the GITHUB_TOKEN rate limit (1,000 requests/hour) and causing HTTP 403 errors that block CI execution entirely. Increasing the polling interval to 20 seconds reduces API call rate by 4x (~120 calls/min across all workflows), keeping the repository well under the rate limit while adding negligible delay to CI completion (the builds themselves take 15-25 minutes).	2 weeks ago
Rene Cannao	f47fa9f909	Enable cluster startup in g5 workflows	2 weeks ago
Rene Cannao	006c78538e	ci: add ci-mysql56-single-g1 reusable workflow ... Context ------- PR sysown/proxysql#5166 (branch 'session-track-system-variable' on v3.0) introduces a new TAP group 'mysql56-single-g1' backed by the 'infra-dbdeployer-mysql56-single' fixture. Three tests are registered against it in 'test/tap/groups/groups.json': - mysql-session_track_variables_enforced-t - mysql-session_track_variables_ff_mysql56-t - mysql-session_track_variables_optional-t The v3.0 side of the PR adds the thin caller 'CI-mysql56-single-g1.yml' which delegates to this reusable. Without this file the caller fails with "workflow not found" when invoked. Changes ------- Adds 'ci-mysql56-single-g1.yml' modelled verbatim on 'ci-mysql84-g1.yml'. The only substantive differences are cosmetic / routing: - 'matrix.infradb: [ mysql56 ]' Per 'doc/GH-Actions/README.md' ("What a sibling differs in") this value is *cosmetic for routing* -- 'ensure-infras.bash' ignores it and picks the real backend from 'test/tap/groups/mysql56-single/infras.lst' (which points at 'infra-dbdeployer-mysql56-single'). The value is, however, *displayed* in the check-run label via 'env.MATRIX', so reviewers see 'CI-mysql56-single-g1 / tests (mysql56)' rather than a misleading 'mysql57' tag. - 'INFRA_ID="ci-mysql56-single-g1"' in the start, run, and cleanup steps. - 'TAP_GROUP="mysql56-single-g1"'. Nothing else changed from the 'ci-mysql84-g1.yml' template: the same sparse checkout, the same ubuntu22-tap src + test cache keys, the same LouisBrunner check-run bracketing, the same 'Fix artifact permissions' sudo chmod workaround for root-owned logs written inside docker containers, and the same always-run cleanup that calls 'stop-proxysql-isolated.bash' followed by 'destroy-infras.bash'. Landing order ------------- This commit ships first on 'GH-Actions', then the caller 'CI-mysql56-single-g1.yml' on v3.0 (already prepared in the session-track-system-variable branch of PR #5166) becomes functional. Between the two commits landing, the caller will fail -- this is the expected window and matches how every existing caller/reusable pair was introduced.	4 weeks ago
Rene Cannao	0e895e6ce3	ci: overwrite expired key that mysql-apt-config.postinst installs ... The previous fix (#5648) imported the renewed RPM-GPG-KEY-mysql-2025 via 'apt-key add -', which writes to /etc/apt/trusted.gpg. That is ignored by /etc/apt/sources.list.d/mysql.list because it carries signed-by=/usr/share/keyrings/mysql-apt-config.gpg and the .postinst script from the mysql-apt-config package dearmors an expired key block (same fingerprint B7B3B788A8D3785C, expiry 2025-10-22) straight into that keyring during 'dpkg -i'. Move the key refresh to AFTER 'dpkg -i mysql-apt-config...' and dearmor the renewed key directly into /usr/share/keyrings/mysql-apt-config.gpg, overwriting the bundled expired copy. The 'apt-key adv --recv-keys 467B942D3A79BD29' line is left intact (unrelated key, unaffected). Verified via dpkg-deb -R on mysql-apt-config_0.8.29-1_all.deb: the opening bytes 'mQINBGU2rNoB...' in postinst match the expired body of repo.mysql.com/RPM-GPG-KEY-mysql-2023 (valid 2023-10-23 → 2025-10-22), while /RPM-GPG-KEY-mysql-2025 carries the renewed copy valid through 2027-10-23. Applies to ci-taptests, ci-taptests-asan, ci-taptests-groups, ci-taptests-old (jammy block), ci-taptests-ssl.	1 month ago
Rene Cannao	833f490cc1	ci: fix expired MySQL APT GPG key (B7B3B788A8D3785C) ... keyserver.ubuntu.com still returns the expired copy of BCA43417C3B485DD128EC6D4B7B3B788A8D3785C, causing every job that installs from repo.mysql.com jammy to fail: W: GPG error: http://repo.mysql.com/apt/ubuntu jammy InRelease: EXPKEYSIG B7B3B788A8D3785C MySQL Release Engineering MySQL re-signed the key with the same fingerprint (valid through 2027-10-23) and publishes it as RPM-GPG-KEY-mysql-2025. Fetch it directly instead of from Ubuntu's keyserver. Hits: ci-taptests, ci-taptests-asan, ci-taptests-groups, ci-taptests-old, ci-taptests-ssl.	1 month ago
Rene Cannao	54365c4050	ci: fix upload-artifact EACCES in all downstream test reusables ... Every downstream test reusable ran actions/upload-artifact@v4 on its ci_*_logs/ output path inside an `if: failure() && !cancelled()` block. When a test actually failed, the upload would die with: ##[error]EACCES: permission denied, scandir '/home/runner/work/ proxysql/proxysql/proxysql/ci_infra_logs/infra-mariadb10-ci-legacy-g3/ mariadb1/mysql' ...because ci_*_logs/ contains files created inside docker build containers as root, which the host-side runner user cannot scandir. Net effect: ZERO post-mortem artifacts for failed test runs. Every maintainer trying to investigate a CI test failure from the Actions page got "no artifacts found" and had to reproduce the failure locally, which is slow and often impossible (CI-specific races). This is the same bug we fixed in ci-builds.yml with sudo (PR #5605), but the fix there only addressed the cache-shrink cleanup paths - it missed every downstream reusable that also wrote to ci_*_logs/ from inside docker and then tried to upload. Fix: before each actions/upload-artifact@v4 step whose path is proxysql/ci_*_logs/, insert a `Fix artifact permissions` step that runs `sudo chmod -R a+rX proxysql/ci_*_logs/` to make the tree world-readable. sudo is required because the files are root-owned. 2>/dev/null + || true because the path may not exist on all failure paths (e.g. a cache-restore failure before the test even runs). Applied to 22 reusable workflow files: - ci-basictests.yml - ci-legacy-clickhouse-g1.yml - ci-legacy-g1.yml, ci-legacy-g2.yml, ci-legacy-g2-genai.yml, ci-legacy-g3.yml, ci-legacy-g4.yml, ci-legacy-g5.yml - ci-mysql84-g1.yml ... ci-mysql84-g5.yml - ci-repltests.yml, ci-shuntest.yml, ci-selftests.yml - ci-taptests.yml, ci-taptests-asan.yml, ci-taptests-old.yml, ci-taptests-ssl.yml, ci-taptests-groups.yml - ci-unittests.yml Not touched: - ci-maketest.yml - uploads ./build-*.log, created by the runner user outside docker, no EACCES - ci-3p-*.yml - these do not upload ci_*_logs/; their artifact uploads (if any) target 3p-specific paths created outside docker - ci-builds.yml - already handled by PR #5605 (sudo rm on test/deps, sudo find on unit binaries) How to verify on a future CI run: if a TAP test fails in any of the patched workflows, `gh api repos/sysown/proxysql/actions/runs/ <run_id>/artifacts` should now return a non-empty list, with the ci_*_logs/ tarball containing the per-test .log.gz files for post-mortem analysis. Before this fix, it returned an empty array for any failed run (because upload-artifact died before emitting anything) - see run 24281031531 on 2026-04-11 as the proof case.	1 month ago
Rene Cannao	0d9da9a9f9	ci: use sudo for cache-prune cleanup to avoid root-owned file errors ... Follow-up to #5603. The ubuntu22-tap CI-builds run on commit 2abbc4f31 failed at the cleanup step with: rm: cannot remove 'test/deps/mariadb-connector-c/mariadb-connector-c-3.1.9/README': Permission denied (thousands of similar lines) [job fails with exit 1 from rm] Root cause ---------- Files under test/deps/ and (potentially) test/tap/tests/unit/ are created inside the docker build container, which runs as root. They land on the host-side workspace mount with root:root ownership. The GitHub-hosted runner user can't always remove those files: unlink requires write access on the parent directory, and deep subdirectories under test/deps (e.g., test/deps/mariadb-connector-c/mariadb-connector-c-3.1.9/zlib/) are themselves root-owned without world-write, so the runner can't remove files inside them. The unit test binary delete in the previous run "worked" (no error reported) only because `find -delete` operates at the file-unlink level and happens to have write access on test/tap/tests/unit/ itself (the leaf directory is runner-writable because it was created via a sparse checkout / repo clone, not inside the docker container). But that's fragile — test/tap/tests/unit/ leaf-directory ownership could change with any future rearrangement. Fix --- Prefix both delete operations with sudo: 1. `sudo find test/tap/tests/unit -type f -name '*-t' -delete` 2. `sudo rm -rf test/deps` GitHub-hosted ubuntu runners have passwordless sudo by default. Sudo is routinely used in CI steps for apt-get, docker cleanup, etc., so this is not adding privilege scope — it's aligning the cleanup step with the privilege level needed to remove files created by another UID. I also added a comment explaining why sudo is needed, so the next maintainer doesn't wonder whether they can remove it. No other behaviour changes. The readelf safety check earlier in the block doesn't need sudo (it only reads files, and readelf errors are swallowed by 2>/dev/null).	1 month ago
Rene Cannao	79868a31b1	ci: shrink _test cache by dropping unit binaries and test/deps ... Context ------- The TAP build target fix in #5601 made CI-builds produce real test binaries in the _test cache. That was necessary (pre-fix, the binaries didn't exist at all and downstream test workflows silently reported PASS 0/0). The unintended consequence was that _test ballooned from ~2 MB compressed to ~4 GB compressed. GitHub's per-repo Actions cache quota is 10 GB. With two active cascades each saving ubuntu22-tap and ubuntu24-tap-genai-gcov caches, we now push ~16 GB of cache into a 10 GB quota, causing LRU eviction between the CI-builds save and the downstream test workflows' restore. "Cache restore test" then fails with fail-on-cache-miss, skipping all real test steps and marking the run as failure after ~5 minutes. The entire TAP pipeline on the safety-net branch cascade today exhibited this failure mode. The cache is dominated by two things we don't actually need in it: 1. test/tap/tests/unit/*-t -- 52 unit test binaries at ~170 MB each (~8.8 GB total) because they statically link libproxysql.a in debug mode. This is the single biggest chunk of the cache. 2. test/deps/ -- ~2.8 GB uncompressed test-framework dependencies (mariadb/mysql connector source + build trees) that TAP binaries link against at build time. Once statically linked, nothing at runtime looks at test/deps. Fix --- In the -tap branch of the CI-builds build step, after generating tap-matrix.txt, prune both from the cache payload. For the unit test binaries: - verify UNIT_COUNT > 0 first (if zero, a unit test failed to compile and the build should fail loudly, not silently ship an empty cache) - find test/tap/tests/unit -type f -name '*-t' -delete For test/deps, before deleting: - iterate every binary under test/tap/tests + test/tap/tests_with_deps - run readelf -d on each - fail the build if any binary has NEEDED libmysqlclient.so, libjson_binlog.so, libstrings_shared.so, or libmariadbclient.so - fail the build if any binary has a RUNPATH / RPATH referencing test/deps If the readelf sweep comes back clean, rm -rf test/deps. The runtime-dependency check is defensive. I verified it holds today for all 380 *-t binaries under test/tap/tests + tests_with_deps (0 dynamic mysql/mariadb deps, 0 test/deps RUNPATH references). If someone adds a dynamically-linked test in the future, they'll hit this check and get a clear error in CI-builds telling them what to fix -- instead of a mysterious "Cache restore test" failure days later when the eviction kicks in. Unit tests are still compiled in CI-builds above (catching unit test compile errors) -- only their binaries are stripped from the cache. CI-unittests on v3.0 is being disabled in a companion PR; when it gets re-enabled it will need its own rebuild strategy (probably a full docker-compose ubuntu22_dbg_build in CI-unittests itself). Expected cache budget after this change --------------------------------------- Pre-fix (broken): ~2 MB compressed _test (no binaries) Post-#5601 (this PR): ~4 GB compressed _test (everything) Post-this-PR: ~1 GB compressed _test (no unit, no test/deps) Budget with 3 concurrent cascades × 2 variants = 6 concurrent _test caches: - Before: 6 × 4 GB = 24 GB (well over 10 GB quota) - After: 6 × 1 GB = 6 GB (fits with ~4 GB headroom) Verified against a fresh local build that all 380 TAP test binaries link the mysql/mariadb client statically and do not have RUNPATH / RPATH entries pointing at test/deps.	1 month ago
Rene Cannao	626a0d23c6	ci: fix TAP build target so test binaries are actually produced ... Changes the CI-builds build command from `make ${dist}-dbg` to `make ${dist}-tap` so that BLD_NAME inside the build container ends with `-tap`, which is what the deb/rhel/suse entrypoint.bash scripts key on to select the `build_tap_test_debug` target instead of the plain `debug` target. Root cause ---------- ci-builds.yml for the `-tap` matrix entries ran: make ${{ matrix.dist }}-dbg which sets BLD_NAME=ubuntu22-dbg (or ubuntu24-dbg), invokes docker compose up ubuntu22_dbg_build, which runs /opt/entrypoint/entrypoint.bash. That script does: elif [[ ${BLD_NAME} =~ \-test|\-tap ]]; then build_target="build_tap_test_debug" else build_target="$PROXYSQL_BUILD_TYPE" # "debug" fi Because BLD_NAME was `ubuntu22-dbg`, the elif didn't match and the else branch ran `make debug` -- which builds lib + src/proxysql but NOT test/tap/tests/**/*-t. The TAP test binaries were never built. On the host, `find test/tap/ -name '*-t'` returned nothing (visible in the CI-builds log as `dirname: missing operand` right after the container exit), the _test cache was ~2 MB of source files only, and downstream test workflows' proxysql-tester.py walks discovered zero test binaries per workdir and reported: SUMMARY: 'tests' PASS 0/0 : FAIL 0/0 : SKIP 0/0 SUMMARY: 'deprecate_eof_support' PASS 0/0 : FAIL 0/0 : SKIP 0/0 SUMMARY: 'unit' PASS 0/0 : FAIL 0/0 : SKIP 0/0 SUMMARY: ret_rc = [0] Zero failures from zero tests = exit 0 = green workflow. The entire TAP test pipeline (CI-legacy-g*, CI-mysql84-g*, CI-basictests, CI-taptests-pgsql-cluster, CI-legacy-clickhouse-g1, CI-legacy-g2-genai) has been silently reporting green while running zero tests. Run 24276110706 (CI-legacy-g1, 2026-04-11) shows the "Run legacy-g1 tests" step completing in 2 seconds with `PASS 0/0` across all three TAP workdirs. Every recent successful run in the history has the same 2-second test step duration. History ------- The original 2023 ci-builds.yml (commit 9235fa492) used a two-stage sed hack to force build_tap_test_debug: sed -i "/command/c \ command: bash -l -c 'cd /opt/proxysql && make build_tap_test_debug WITHGCOV=1'" docker-compose.yml make ${{ matrix.dist }}-dbg In April 2025, commit 8454e642c added the BLD_NAME-based routing to entrypoint.bash so callers could just invoke `make ${dist}-tap` instead of the sed hack. In March 2026, commit 6e7d93229 re-added ci-builds.yml on the GH-Actions branch with the sed lines commented out but the make target left at `-dbg`. Neither the sed mechanism nor the entrypoint mechanism was active, so the TAP build was skipped silently. Fix --- Change `make ${{ matrix.dist }}-dbg` to `make ${{ matrix.dist }}-tap` in the `-tap` branch of the build step. The `-tap` suffix makes entrypoint.bash select `build_tap_test_debug`, which recursively builds build_src_debug (producing src/proxysql) and then runs `cd test/tap && make debug` to build all TAP test binaries. The workspace bind-mount (./:/opt/proxysql/) makes those binaries visible to the host after the container exits. Expected post-fix behaviour: - `find test/tap/ -name '*-t'` returns 300+ results - tap-matrix.json is non-empty - _test cache grows from ~2 MB to something proportional to the number of TAP binaries - proxysql-tester.py actually runs tests and CI-legacy-g* / CI-mysql84-g* runs take 10-60 minutes instead of 2 seconds	1 month ago
Rene Cannao	6bedcb08cc	ci: fix misleading mysql57 label on ci-mysql84-g{1..5} check runs ... The five ci-mysql84-g*.yml reusables introduced in #5597 inherited `infradb: [ 'mysql57' ]` from ci-legacy-g4.yml as the sed template. The `infradb` matrix value is interpolated into `env.MATRIX` and then into the check-action step's `name` field, so the GitHub PR UI would display check runs as `CI-mysql84-g3 / tests (mysql57)` even though the tests themselves are correctly running against infra-mysql84. The infrastructure resolution is unaffected -- `ensure-infras.bash` strips the -gN suffix from TAP_GROUP=mysql84-g3 to get BASE_GROUP=mysql84, which resolves to test/tap/groups/mysql84/infras.lst (infra-mysql84). This is purely a display-name fix. Set infradb to 'mysql84' in all five files so the check run name matches the backend actually under test. Caught by gemini-code-assist review on #5598.	1 month ago
Rene Cannao	412f7d2f86	ci: add dedicated reusable workflows for legacy-g{1,3,5}, mysql84-g{1..5}, unit-tests ... Adds 9 per-group reusable workflows modeled on ci-legacy-g4.yml, which together with the existing ci-legacy-g2/g2-genai/g4/clickhouse-g1 cover all the CI-legacy-* and CI-mysql84-* callers that currently live on v3.0. Previously those callers routed to the generic ci-taptests-groups.yml, whose tests job sources its matrix from a cached proxysql/tap-matrix.json that recent CI-builds runs populate as "[ ]". With an empty matrix vector GitHub rejects the strategy ("Matrix vector 'testgroup' does not contain any values") and the tests job never instantiates - see run 24240099115 for an example. Each new reusable: - drives tests via TAP_GROUP + INFRA_ID, delegating infra resolution to test/infra/control/ensure-infras.bash (which looks up the per-group env.sh / infras.lst under test/tap/groups/) - keeps SKIP_CLUSTER_START=1 (safe default - only the pgsql cluster sync workflow needs the cluster started) - drops TAP_USE_NOISE=1 (g4-specific; leave other groups to opt in) ci-unittests.yml is slimmed down (no docker base build, no ensure/destroy) because the unit-tests group sets SKIP_PROXYSQL=1, which makes run-tests-isolated.bash take its host-only branch and execute the 42 *_unit-t binaries discovered from groups.json directly on the runner.	1 month ago
Rene Cannao	9ef3913978	ci: add reusable workflows for legacy-g4 and legacy-clickhouse-g1 ... Adapted from ci-legacy-g2.yml: - ci-legacy-g4.yml: runs legacy-g4 TAP test group (mysql57 infra) - ci-legacy-clickhouse-g1.yml: runs legacy-clickhouse-g1 TAP tests (clickhouse23 infra) Both follow the same pattern: checkout, cache restore, build CI base image, start infrastructure, run tests via run-tests-isolated.bash, cleanup, upload artifacts on failure.	2 months ago
Rene Cannao	08a19245b5	Fix summary log glob: match subdirectory layout ./logs/${NOW}/*_summary.log ... fn_summary in common.bash writes to ./logs/${NOW}/${SUITE}_summary.log (e.g. ./logs/20260325-002217/aiomysql_summary.log) but Check baseline was looking for ./logs/*_summary.log — and shell glob * doesn't cross directory boundaries. Changed to ./logs/*/*_summary.log to match the actual file location in the ${NOW} timestamped subdirectory.	2 months ago
Rene Cannao	fdd87c677a	Fix false-green CI in all 3p test workflows ... The "Check baseline" step in all 10 ci-3p-*.yml workflows could report success even when tests completely failed or never ran, because: 1. Missing summary log → FAILS variable empty → exit ${FAILS:-0} → exit 0 2. pytest ERROR counts (fixture/setup failures) were ignored, only FAIL counts were checked — so tests that all error at setup showed as green 3. Unparseable summary log format → same empty FAILS → false success 4. "Check baseline" had no if: condition, so it was skipped when "Run tests" failed, letting run-tests.bash's exit code (often 0) stand 5. Artifacts were only uploaded on failure(), but failure was never detected, destroying debug evidence Fixes applied to all 10 workflows: - Add if: !cancelled() to "Check baseline" so it always evaluates results - Fail explicitly when summary log is missing - Fail explicitly when FAIL count cannot be parsed - Parse and fail on ERROR count (setup/fixture failures) - Change artifact upload from failure() to !cancelled() for always-on logs - Fix inconsistent artifact naming (missing dash before 'logs')	2 months ago
René Cannaò	6e7d932294	Add CI-legacy-g2-genai reusable workflow (ubuntu24-tap-genai-gcov)	2 months ago
René Cannaò	a121ddfe4e	Add CI-legacy-g2 reusable workflow (ubuntu22-tap)	2 months ago
René Cannaò	8ad8ec9cc2	Add ubuntu24-tap-genai-gcov build matrix entry	2 months ago
René Cannaò	b1ea145c51	Fix CI-basictests: checkout before cache restore, add binary verification and debug logging	2 months ago
René Cannaò	6ff43e8ef5	Migrate CI-basictests from jenkins-build-scripts to in-repo test/infra (#5522)	2 months ago
Miro Stauder	6057930450	add another runname	3 months ago
Miro Stauder	548284ce9c	fix typo	3 months ago
Miro Stauder	c12b13e9cc	fix run name	3 months ago
Miro Stauder	8502fab2e3	fix runname	3 months ago
Miro Stauder	8ca0029263	lowe verbosity	3 months ago
Miro Stauder	b6fa0b2877	fix typo	3 months ago
Miro Stauder	bb7267922b	update docker-hoster image	3 months ago
Miro Stauder	1ec0c3e201	use updated docker-hoster	3 months ago
Miro Stauder	4f440a4591	Update ci-repltests.yml ... Signed-off-by: Miro Stauder <miro@proxysql.com>	3 months ago
Miro Stauder	7d8aba0c6e	Update ci-builds.yml ... Signed-off-by: Miro Stauder <miro@proxysql.com>	3 months ago
Miro Stauder	144fec3750	Update ci-builds.yml ... Signed-off-by: Miro Stauder <miro@proxysql.com>	3 months ago
Miro Stauder	fff2a8f095	Update ci-shuntest.yml ... Signed-off-by: Miro Stauder <miro@proxysql.com>	3 months ago
Miro Stauder	fb8e6f9126	Update ci-shuntest.yml ... Signed-off-by: Miro Stauder <miro@proxysql.com>	3 months ago
Miro Stauder	714c768b48	Update ci-builds.yml ... Signed-off-by: Miro Stauder <miro@proxysql.com>	4 months ago
Miro Stauder	2365ab230b	Update ci-basictests.yml ... Signed-off-by: Miro Stauder <miro@proxysql.com>	4 months ago
Miro Stauder	d14141fec0	Update ci-3p-pgjdbc.yml ... Signed-off-by: Miro Stauder <miro@proxysql.com>	4 months ago
Miro Stauder	c4ad3c2cd2	Update ci-basictests.yml ... Signed-off-by: Miro Stauder <miro@proxysql.com>	4 months ago
Miro Stauder	18669fc405	Update ci-basictests.yml ... Signed-off-by: Miro Stauder <miro@proxysql.com>	4 months ago
Miro Stauder	8a401563b2	use explicit branch ... Signed-off-by: Miro Stauder <miro@proxysql.com>	7 months ago
Miro Stauder	1bcab4180e	Update ci-taptests-groups.yml ... Signed-off-by: Miro Stauder <miro@proxysql.com>	8 months ago