proxysql

Commit Graph

Author	SHA1	Message	Date
Rene Cannao	c8703aba52	fix(ci): use ubuntu24-tap-genai-gcov cache key in pgsql-socket-g1 ci-pgsql-socket-g1.yml restored a build cache keyed ${SHA}_ubuntu24-tap_src — but CI-builds' matrix never emits that variant. The only ubuntu24 entry produces ${SHA}_ubuntu24-tap-genai -gcov_src, which is what every sibling workflow (ci-mysql84-g1, ci-legacy-g1, ci-mariadb10-galera-g1, …) reads. With fail-on-cache-miss: true the job aborts at the cache-restore step and never runs a single test — surfacing as a "tests failure" that's actually a key typo introduced when the workflow was added in `d32ca0172`. Align the _src + _test keys with the working siblings; no logic change.	2 weeks ago
René Cannaò	9476fb735e	Merge pull request #5845 from sysown/ci-pgsql-socket-g1 ci: add pgsql-socket-g1 reusable workflow	3 weeks ago
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
René Cannaò	9b95211450	Merge pull request #5829 from sysown/ci/zstd-level-15 ci(cache): drop pre-compression from zstd --ultra -22 to zstd -15	1 month 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
René Cannaò	30dffb30a0	Merge pull request #5827 from sysown/feature/ci-codecov-tap-all-groups-callees ci(coverage): extend Codecov TAP upload to all remaining TAP groups	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
René Cannaò	d2c9a83262	Merge pull request #5821 from sysown/fix/ci-cache-restore-path fix(ci): align Cache restore src path with CI-builds save path	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
René Cannaò	350c2b461d	Merge pull request #5812 from sysown/ci-trigger-tolerate-cleanup-401 ci(trigger): tolerate per-call HTTP 401 in cleanup step (fixes #5811)	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
René Cannaò	aa1f1250c7	Merge pull request #5787 from sysown/fix/galera-g5-cluster-start fix(ci): start the proxysql cluster on mariadb10-galera-g5	2 months 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
René Cannaò	57bda737c1	Merge pull request #5759 from sysown/ci-mariadb10-galera-GH-Actions feat(ci): add reusable workflows for CI-mariadb10-galera-g[1-9] test groups	2 months ago
Rene Cannao	62123bd370	feat(ci): add reusable workflows for CI-mariadb10-galera-g[1-9] test groups	2 months ago
René Cannaò	d1b4fb783f	Merge pull request #5757 from sysown/ci/fix-gr-g5-cluster-start fix(ci): remove SKIP_CLUSTER_START=1 from mysql84-gr-g5 workflow	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
René Cannaò	3395ecc6e5	Merge pull request #5754 from sysown/ci-mysql84-gr-g1-g9-GH-Actions feat(ci): add reusable workflows for CI-mysql84-gr-g[1-9] test groups	2 months ago
Rene Cannao	ad296936ae	feat(ci): add reusable workflows for CI-mysql84-gr-g[1-9] test groups	2 months ago
René Cannaò	0194e84078	Merge pull request #5751 from sysown/perf/pull-ci-base-from-ghcr perf(ci): pull pre-built proxysql-ci-base from GHCR	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
René Cannaò	a301561c63	Merge pull request #5750 from sysown/fix/split-test-groups feat(ci): add reusable workflows for split test groups g6-g9	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
René Cannaò	a89c730193	Merge pull request #5749 from sysown/fix/rename-set-parser-workflow fix(ci): rename set_parser_algorithm=3 workflow to avoid Docker network issue	2 months ago
Rene Cannao	aa465bbc54	fix(ci): rename set_parser_algorithm=3 workflow to avoid Docker network issue	2 months ago
René Cannaò	26d91c2a53	Merge pull request #5747 from sysown/gh-actions/add-set-parser-algorithm-3-g1 ci: add ci-set_parser_algorithm=3-g1 reusable workflow	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
René Cannaò	6db90dac35	Merge pull request #5719 from sysown/ci-reduce-polling-interval ci: reduce API polling interval from 5s to 20s	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
René Cannaò	77994a3692	Merge pull request #5716 from sysown/ci-g5-enable-cluster Enable cluster startup in g5 CI workflows	2 months ago
Rene Cannao	f47fa9f909	Enable cluster startup in g5 workflows	2 months ago
René Cannaò	2824d8c812	Merge pull request #5657 from sysown/GH-Actions-mysql56-single-g1 ci: add reusable workflow for mysql56-single-g1	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
René Cannaò	0ae7e2cde6	Merge pull request #5649 from sysown/ci/fix-mysql-apt-key-expired-v2 ci: overwrite the expired key that mysql-apt-config.postinst installs	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
René Cannaò	04a1cbf8a5	Merge pull request #5648 from sysown/ci/fix-mysql-apt-key-expired ci: fix expired MySQL APT GPG key (B7B3B788A8D3785C)	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

1 2 3 4 5 ...

6660 Commits (ci/fix-pgsql-socket-g1-cache-key) All Branches Search

6660 Commits (ci/fix-pgsql-socket-g1-cache-key)

All Branches