proxysql

Commit Graph

Author	SHA1	Message	Date
Rene Cannao	d32ca01728	ci: add pgsql-socket-g1 reusable workflow Adds the reusable workflow that backs the CI-pgsql-socket-g1 caller on v3.0. Mirrors the structure of ci-legacy-g1.yml so the caller can delegate to it via 'uses: sysown/proxysql/.github/workflows/ ci-pgsql-socket-g1.yml@GH-Actions' without changes to permissions, matrix, or Codecov upload mechanics. This workflow runs the docker-pgsql16-single infra (extended by the pgsql-socket TAP group setup hook to expose a Unix-domain socket at /var/run/postgresql-shared) and executes the pgsql-unix_socket-t TAP regression test added by PR #5844. Caller shim is in PR #5844 and depends on this reusable being merged first.	3 weeks ago
Rene Cannao	18d4d92eab	ci(cache): drop pre-compression from zstd --ultra -22 to zstd -15 Follow-up to `4e4d4496a`, which introduced pre-compression at `--ultra -22` to fit the _test/_bin caches under GitHub's 10 GB per-repo cache quota. The size win is real, but the time cost was not properly accounted for: Last green CI-builds run (`97eab1bbf0`): ubuntu24-tap-genai-gcov: build 17m58s, pack-bin 3m11s, pack-test 15m53s ubuntu22-tap: build 17m54s, pack-bin 2m51s, pack-test 14m08s `pack-test` alone takes roughly as long as the actual build at `--ultra -22`, pushing CI-builds wall clock to ~38 min and gating every downstream TAP-group workflow on it. With PR #5827/#5828 fanning coverage out to ~38 TAP groups, the compounded idle time was intolerable. Switching to zstd -15: - keeps actions/cache@v4 free of double compression (already- compressed .tar.zst is essentially a no-op on the action's own level-3 pass), preserving the original anti-LRU motivation; - captures most of the size headroom -- empirically -15 vs --ultra -22 trades roughly 5-7% extra blob size for ~10x faster compression; - takes pack-test from ~15 min down to an expected 1-3 min per ubuntu job, cutting ~12-14 min off the critical path of every CI-builds invocation. If the quota turns out to be too tight at -15 we can revisit -19 (the canonical "high-compression sweet spot"), but -22 --ultra was clearly over the line. No changes to cache keys, no consumer-side changes needed -- the .tar.zst format is identical, only the compression level inside the blob differs.	1 month ago
Rene Cannao	e59e55b0a3	ci(coverage): extend Codecov TAP upload to all remaining TAP groups Fan-out of PR #5818's two-line pattern to every TAP-group reusable workflow that wasn't yet contributing to Codecov: legacy-clickhouse-g1, legacy-g1, legacy-g3..g9, mariadb10-galera-g1..g9, mysql56-single-g1, mysql84-g1..g9, mysql84-gr-g1..g9, set_parser_algorithm_3-g1 (38 reusables total) For each ci-<group>.yml on GH-Actions: - permissions: write-all (id-token:write for codecov OIDC) - BLDCACHE -> ubuntu24-tap-genai-gcov_src (was ubuntu22-tap_src) - test cache key -> ubuntu24-tap-genai-gcov_test - MATRIX label gains ",genai-gcov" - "Run <group> tests" step exports COVERAGE=1 - Archive coverage report (LCOV .info) as artifact - Upload to Codecov tagged flags: tap-<group> The non-gcov ubuntu22-tap_src path is no longer referenced by any TAP group; CI-builds still produces it but it can be pruned in a follow-up once everything is observed green. The caller side (CI-<group>.yml on v3.0 declaring permissions: write-all so id-token:write propagates through the reusable call) is the companion change.	1 month ago
Rene Cannao	4e4d4496aa	ci(cache): pre-compress _test/_bin caches with zstd --ultra -22 `actions/cache@v4` ships its payload through zstd at level ~3. The _test and _bin caches saved by CI-builds and consumed by every downstream TAP/3p workflow add up to several GB each and routinely push the repo past GitHub's 10 GB per-repo cache quota. The LRU eviction that follows deletes caches between save and restore, breaking the entire TAP pipeline with cryptic "Cache restore test" failures. Wrap both caches so they travel as `cache_<kind>.tar.zst`: - In CI-builds: add a "Pack <kind> cache with zstd-22" step that does `tar -cf - <paths> \| zstd --ultra -22 -T0 -o ../cache_<kind>.tar.zst` before the `actions/cache/save@v4` step. The save now uploads a single .tar.zst blob; the action's level-3 re-compression on already-maximally-compressed data is a near no-op. - In every consumer workflow (55 files): change the restore `path:` to the single-line scalar `cache_<kind>.tar.zst` and add an "Unpack <kind> cache" step right after that does `zstd -d < ../cache_<kind>.tar.zst \| tar -xf -` from inside `proxysql/`, recreating the original layout (`proxysql/test/`, `proxysql/.git/`, `proxysql/binaries/`). Footprint reduction is ~25-30% on the wire, which is enough headroom to keep two concurrent cascades under the 10 GB quota. Compatibility note: the cache version embeds the path list, so this change invalidates the existing _test/_bin caches. The first run on a given SHA after this lands has to rebuild; subsequent runs hit the new compressed cache normally. Old caches age out via LRU. The cache key format itself (including all `_test` / `_bin` / `_src` / `_matrix` suffixes and per-shard `inputs.trigger`/`github.sha` expressions) is preserved verbatim. Scope: only `_test` and `_bin` caches are touched. `_src`, `_matrix`, `_3p-*`, codeql, and other caches are left alone.	1 month ago
Rene Cannao	68d9f3e2c5	fix(ci): align Cache restore src path with CI-builds save path `actions/cache@v4` hashes the `paths`, `key`, and `enableCrossOsArchive` flag together into a "version" identifier. When save and restore disagree on paths, the version differs and the restore silently misses — even if the key matches an entry that plainly exists in the repo cache. ci-builds.yml saves `Cache save src` with: path: \| proxysql/src/ proxysql/lib/obj/.gcno The second entry was added so the `-gcov` variants can capture lib/obj/.gcno (needed by fastcov to map .gcda → source files). It's a no-op for non-gcov variants — the glob matches nothing — but it changes the computed version, so every restore step needs the same two-line path list to find the saved entry. `ci-legacy-g2-genai.yml` was already fixed and carries a comment documenting the gotcha. The other 47 test workflows still had only `proxysql/src/` on the restore side, producing "Failed to restore cache entry" on every PR. Aligning them with the save path here unblocks the test cascade across the board. ci-codeql.yml is left alone — its Cache restore src block is fully commented out, so there's nothing to align.	1 month ago
Rene Cannao	b2d54cf1bb	ci(coverage): disable_file_fixes on Codecov upload to dodge codecov-cli crash The previous run finally produced real coverage data -- 38.1% line coverage (32204/84621 lines) of the actual ProxySQL daemon running the legacy-g2 TAP integration suite. But the Codecov upload step crashed mid-upload with: FileNotFoundError: [Errno 2] No such file or directory: 'proxysql/test/afl_digest_test/c_tokenizer.cpp' [PYI-11054:ERROR] Failed to execute script 'main' due to unhandled exception! in codecov-cli's _get_file_fixes step. That step reads every source file referenced in the LCOV report to compute line-offset adjustments for Codecov's PR diff annotations. fastcov runs inside the test container at cwd=/opt/proxysql and embeds paths like `proxysql/test/afl_digest_test/c_tokenizer.cpp` in the report -- not all of those test subdirs are restored on the runner because the _test cache prunes test deps to keep the cache under GitHub's 10 GB repo quota, so the file-fixes pass blows up on the first missing path. `disable_file_fixes: true` on codecov-action@v4 skips the entire step. Aggregate coverage numbers (the bit users actually look at) are not affected; only Codecov's inline PR diff annotations may be less precisely aligned. That's a fair trade for getting the upload to actually land.	1 month ago
Rene Cannao	f863f49749	ci(coverage): align cache restore path with save path in legacy-g2-genai Root cause of every "Failed to restore cache entry" we've been chasing for the last two hours. actions/cache@v4 hashes the path list into the cache "version" (alongside compressionMethod and runner OS) and uses (key, version) as the lookup tuple. The CI-builds "Cache save src" step added proxysql/lib/obj/*.gcno to its path list (needed to ship daemon-side .gcno files to the test workflow's fastcov), which changed the version hash. This restore step was still using only `proxysql/src/`, computing a different version, and looking up a cache entry that doesn't exist -- even though the cache for the same (sha, key) plainly exists in the repo. The earlier rabbit hole through checks:write, packages:read, actions:read, actions:write, write-all, and freeing the cache quota were all unrelated; the cache restore would have still missed on any permission set because the lookup tuple was wrong. Fix: mirror the save-side path list exactly. Also leaves a long comment so the next person who modifies either end of the cache learns this without burning a session on it.	1 month ago
Rene Cannao	81c5b4fc45	ci(coverage): use write-all permissions for legacy-g2-genai Five iterations of "add the next missing scope" still left cache restore failing in workflow_dispatch mode even with actions:write explicitly granted. The diagnostic was unhelpful -- the cache plainly exists (verified via gh api), the token shows Actions:write, but actions/cache/restore@v4 still says "Failed to restore cache entry". The cascading workflow_run runs that successfully restore the same caches use default GITHUB_TOKEN (no `permissions:` block), and the rest of the TAP group workflows in this repo do the same. The only ProxySQL-specific need over those defaults is id-token:write for codecov-action@v4's OIDC upload, and write-all grants both that and every default scope. Trade-off: write-all is broader than the audited five-scope list we arrived at, but provably works, matches the rest of the repo's posture, and removes the surprise factor for the next maintainer who tries to add a permission-gated action to this workflow. Mirror commit on v3.0 (caller) required.	1 month ago
Rene Cannao	ee763bc4b9	ci(coverage): bump actions:read -> actions:write for legacy-g2-genai The previous addition of actions:read (`74637fc19`) was the documented minimum for actions/cache/restore@v4, but in practice the restore still fails with "Failed to restore cache entry" even though the cache key plainly exists. The successful cascade runs use the default GITHUB_TOKEN, which grants actions:write -- the asymmetry suggests cache lookup goes through the same code path as cache save, and the API gates both behind the write scope regardless of operation direction. Bumping to actions:write to match what the cascade runs have. This is the same scope the default token gets when no `permissions:` block is declared, so there's no privilege escalation -- we're just explicitly re-granting what we accidentally dropped.	1 month ago
Rene Cannao	74637fc194	ci(coverage): add actions:read for cache restore in legacy-g2-genai Third instance of the same root cause: declaring `permissions:` makes the list exhaustive; every default scope not listed is revoked from GITHUB_TOKEN. actions/cache/restore@v4 reads cached build artifacts via the GitHub Actions cache API, which requires actions:read. Without the grant, the restore step fails with: Failed to restore cache entry. Exiting as fail-on-cache-miss is set. Input key: <SHA>_ubuntu24-tap-genai-gcov_src even when the cache plainly exists. The job then skips the test step, no .info file is produced, and Codecov uploads nothing useful -- same blast radius as the previous checks:write and packages:read regressions. This should close the last default-permission gap. The grants now cover: contents:read checkout id-token:write Codecov OIDC upload checks:write LouisBrunner/checks-action packages:read GHCR docker pull actions:read cache restore	1 month ago
Rene Cannao	a4d90cbc51	ci(coverage): include lib/obj/.gcno in _src cache for gcov builds The _src cache currently saves `proxysql/src/` only. For non-gcov builds that's enough -- src/ contains the proxysql binary plus src/obj/.{oo,gcno}. But for -gcov variants the daemon's runtime .gcda files (under /gcov inside the test container) cover lib/ sources too: MySQL_Query_Processor, c_tokenizer, Admin_Handler, PgSQL_Session, etc. The matching .gcno files live in lib/obj/ inside the build container -- and they never make it into the cache, so they're not present when the test workflow tries to map .gcda back to source. That's why CI-legacy-g2-genai has been producing 0-byte ci-legacy-g2-genai.info files for as long as COVERAGE=1 has existed: fastcov sees 226 .gcda files, none of them have a matching .gcno, and every one is logged as "Missing 'current_working_directory'" with an empty files list. The bug was masked because the resulting .info file was archived as a workflow artifact nobody downloaded; the Codecov upload step added in `6335dca47` made it visible by sending the empty file to Codecov, where it shows as 0%. This commit adds `proxysql/lib/obj/.gcno` to the cache path. The glob is a no-op on non-gcov builds (lib/obj/.gcno doesn't exist there), and adds only a few MB to the gcov cache (~100 .cpp files in lib/, .gcno ~50-200 KB each). Pair this with the basename-based .gcno lookup in test/infra/control/run-tests-isolated.bash (separate commit on v3.0) to actually produce non-empty coverage reports.	1 month ago
Rene Cannao	a65182a876	ci(coverage): add packages:read for GHCR pull in legacy-g2-genai Second instance of the same pattern as the previous commit (`4da8dcda6`): declaring an explicit `permissions:` block on the job makes the list exhaustive, so any default scope not listed is revoked from GITHUB_TOKEN. checks:write was the first casualty; packages:read is the second. The "Log in to GHCR and pull CI base image" step uses GITHUB_TOKEN as `--password-stdin` for `docker login ghcr.io` and then pulls `ghcr.io/sysown/proxysql-ci-base:latest`. Without packages:read, all 5 retry attempts in the existing backoff loop receive "Error response from daemon: denied" and the step fails. That cascades every subsequent test step to skipped (same blast radius as the checks:write regression), so no .info file is produced and the Codecov upload step finds nothing to send. Validated by run 26419812678. Adding packages:read closes the last known default-permission gap; the next dispatch should produce real coverage.	1 month ago
Rene Cannao	4da8dcda6a	ci(coverage): add checks:write permission to legacy-g2-genai Adding the explicit `permissions:` block in the previous commit (`6335dca47`) inadvertently shrunk GITHUB_TOKEN's scope from "all defaults" to "exactly contents:read + id-token:write", because that's how GitHub Actions permission semantics work -- declaring the block makes it exhaustive, not additive. The unintended consequence: LouisBrunner/checks-action@v2.0.0 at step 2 of the job POSTs to /check-runs to publish an in-progress check, and that endpoint needs `checks: write`. Without it the step failed on permission, which cascaded every subsequent step with no explicit `if:` to "skipped" -- including the actual "Run legacy-g2 tests (GenAI + Coverage)" step. The job published no .info file but the Codecov upload step still ran (it has `if: !cancelled()`) and reported success on an empty/missing input, which masked the real failure. Adding `checks: write` restores LouisBrunner; the test step then runs, produces the LCOV report, and the Codecov upload sends real data. Validated via dispatch on feature/ci-codecov-tap-legacy-g2 next.	1 month ago
Rene Cannao	6335dca474	ci(coverage): upload legacy-g2 TAP coverage to Codecov via OIDC The CI-legacy-g2-genai pipeline already builds proxysql with WITHGCOV=1 (via the -tap-genai-gcov build cache) and runs it as the live daemon answering the legacy-g2 TAP integration suite. The existing run-tests-isolated.bash COVERAGE=1 path produces an LCOV .info file at ci_infra_logs/ci-legacy-g2-genai/coverage-report/ ci-legacy-g2-genai.info and archives it as a workflow artifact. This commit ships that same file to Codecov so the coverage graph at app.codecov.io/github/sysown/proxysql/ reflects real ProxySQL coverage -- the daemon exercised by integration tests -- in addition to the lib-only unit-test slice that CI-unit-tests-asan-coverage already uploads. Mechanics: - `flags: tap-legacy-g2` lets Codecov merge per-group uploads and surface per-flag coverage trends later when other groups join. - `use_oidc: true` is mandatory. The repo has no CODECOV_TOKEN secret (the Codecov UI hides per-repo tokens for public repos with the GitHub App installed); legacy tokenless uploads are rejected by Codecov with "Token required because branch is protected" HTTP 400. See Phase 1 history on CI-unit-tests-asan-coverage.yml for the diagnosis. - `permissions: id-token: write` on the tests job lets Actions mint the OIDC token. The caller workflow CI-legacy-g2-genai.yml on v3.0 grants the same permission so it can propagate through the reusable-workflow call (callee permissions are caller-intersected). - `fail_ci_if_error: false` + `if: !cancelled()` keep Codecov outages and partial-failure runs from gating the TAP group. This is the first TAP group with Codecov upload. Once validated, the same two-line pattern (cache key flip to -tap-genai-gcov + upload step) can be replicated to other groups, with each picking its own `flags:` value so Codecov shows per-group contribution.	1 month ago
Rene Cannao	4f041de3c5	ci(trigger): tolerate per-call HTTP 401 in cleanup step (fixes #5811 ) `CI-trigger`'s "Trigger workflow_run[completed]" step does opportunistic housekeeping by listing every skipped run in the repo and trying to delete each one. Some of those runs (typically from forked PRs, other branches, or older retention windows) are not deletable by the PR-scoped `GITHUB_TOKEN`, which surfaces as `HTTP 401: Bad credentials` on the individual `gh run delete` call. The original pipeline used `xargs -r -n1 gh run delete`, which propagates the first non-zero exit and fails the whole step. That in turn marks the `CI-trigger` job conclusion as `failure`, and every downstream test workflow that gates on `workflow_run.conclusion == 'success'` (legacy-g, mysql84-, mysql84-gr-*, set_parser_algorithm_3-g1, ...) is silently skipped. Net result: a non-critical housekeeping failure blocks the entire test matrix for the PR. It's been the recurring cause of "why is CI failing on my PR" today, biting PR #5803, PR #5809, and others. Switch from `xargs` to a `while read` loop so per-call failures are caught individually, logged for visibility, and don't abort the step. Cleanup scope is unchanged (still repo-wide, still capped at the most recent 100 skipped runs) -- only the error-handling behavior changes.	1 month ago
René Cannaò	4b53979c07	Merge pull request #5793 from sysown/fix/ghcr-pull-retry fix(ci): retry transient GHCR login + pull failures	1 month 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.	2 months 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`.	2 months ago
Rene Cannao	62123bd370	feat(ci): add reusable workflows for CI-mariadb10-galera-g[1-9] test groups	2 months 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 months ago
Rene Cannao	ad296936ae	feat(ci): add reusable workflows for CI-mysql84-gr-g[1-9] test groups	2 months 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 months 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 months 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 months ago
Rene Cannao	aa465bbc54	fix(ci): rename set_parser_algorithm=3 workflow to avoid Docker network issue	2 months 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 months 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 months ago
Rene Cannao	f47fa9f909	Enable cluster startup in g5 workflows	2 months 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.	2 months 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.	2 months 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.	2 months 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.	3 months 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).	3 months 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.	3 months 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	3 months 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.	3 months 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.	3 months 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.	3 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.	3 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')	3 months ago
René Cannaò	6e7d932294	Add CI-legacy-g2-genai reusable workflow (ubuntu24-tap-genai-gcov)	3 months ago
René Cannaò	a121ddfe4e	Add CI-legacy-g2 reusable workflow (ubuntu22-tap)	3 months ago
René Cannaò	8ad8ec9cc2	Add ubuntu24-tap-genai-gcov build matrix entry	3 months ago
René Cannaò	b1ea145c51	Fix CI-basictests: checkout before cache restore, add binary verification and debug logging	3 months ago
René Cannaò	6ff43e8ef5	Migrate CI-basictests from jenkins-build-scripts to in-repo test/infra (#5522 )	3 months ago
Miro Stauder	6057930450	add another runname	4 months ago
Miro Stauder	548284ce9c	fix typo	4 months ago
Miro Stauder	c12b13e9cc	fix run name	4 months ago
Miro Stauder	8502fab2e3	fix runname	4 months ago
Miro Stauder	8ca0029263	lowe verbosity	4 months ago

1 2 3 4 5 ...

869 Commits (ci-pgsql-socket-g1)