-
Notifications
You must be signed in to change notification settings - Fork 1.1k
test: add targeted GCOV TAP workloads #6085
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
c299e21
4cf25ac
7443974
78ef83b
5c7ca08
939e432
647902b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,23 @@ | ||
| name: CI-mysql84-binlog-g1 | ||
| run-name: '${{ github.event.workflow_run && github.event.workflow_run.head_branch || github.ref_name }} ${{ github.workflow }} ${{ github.event.workflow_run && github.event.workflow_run.head_sha || github.sha }}' | ||
|
|
||
| on: | ||
| workflow_dispatch: | ||
| workflow_run: | ||
| workflows: [ CI-trigger ] | ||
| types: [ completed ] | ||
|
|
||
| concurrency: | ||
| group: ${{ github.workflow }}-${{ github.event.workflow_run && github.event.workflow_run.head_branch || github.ref_name }} | ||
| cancel-in-progress: true | ||
|
|
||
| jobs: | ||
| run: | ||
| if: ${{ github.event.workflow_run && github.event.workflow_run.conclusion == 'success' || ! github.event.workflow_run }} | ||
| # The reusable workflow mints a Codecov OIDC token. Permissions are | ||
| # intersected across caller and callee, so the caller also grants write-all. | ||
| permissions: write-all | ||
|
Check warning on line 19 in .github/workflows/CI-mysql84-binlog-g1.yml
|
||
| uses: sysown/proxysql/.github/workflows/ci-mysql84-binlog-g1.yml@GH-Actions | ||
|
Check failure on line 20 in .github/workflows/CI-mysql84-binlog-g1.yml
|
||
| secrets: inherit | ||
|
Check warning on line 21 in .github/workflows/CI-mysql84-binlog-g1.yml
|
||
| with: | ||
| trigger: ${{ toJson(github) }} | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,268 @@ | ||
| # GTID, Aurora, and Admin Coverage Implementation Plan | ||
|
|
||
| > For agentic workers: REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox syntax for tracking. | ||
|
|
||
| Goal: Execute the existing GTID causal workload in GCOV CI and add behaviorally asserted Aurora and Admin TAP workloads for previously unexecuted coverage paths. | ||
|
|
||
| Architecture: No production code changes. Register the existing GTID TAP in the MySQL 8.4 coverage group only after a focused proof run. Add one Aurora simulator-group TAP that supplies deterministic monitor state and sends normal libmysql traffic through ProxySQL, plus one MySQL 8.4 TAP for live Admin commands. | ||
|
|
||
| Tech Stack: C++17 TAP/libmysqlclient, ProxySQL admin SQL, existing cluster simulator, groups.json, GCOV/fastcov. | ||
|
|
||
| ## Execution evidence (2026-08-15) | ||
|
|
||
| - The existing GTID TAP passed its focused MySQL 8.4 run (14 assertions) after | ||
| isolating its high-priority routing rules with a dedicated frontend account. | ||
| Compiler-matched GCOV recorded the intended GTID branch in `lib/MyHGC.cpp`. | ||
| - The new Aurora TAP passed all 9 assertions using a normal libmysql frontend | ||
| query. It opened a connection to the eligible nonzero-lag replica only and | ||
| increased the Aurora skipped-replica counter. | ||
| - The new Admin TAP passed all 23 assertions. Compiler-matched GCOV recorded | ||
| the intended `PROXYSQLTEST` cases 1/2/3/6/12/13/16 in | ||
| `lib/ProxySQL_Admin_Tests2.cpp`. | ||
|
|
||
| ## Global Constraints | ||
|
|
||
| - Use normal libmysql client traffic for every ProxySQL request; no handcrafted client protocol packets. | ||
| - Use TEST_AURORA only to supply Aurora monitor state; assert endpoint selection and status effects from the frontend query. | ||
| - Restore Admin state through LOAD ... FROM DISK and LOAD ... TO RUNTIME. | ||
| - Add tests only to mysql84-g5 and cluster_sim_aurora-g1. | ||
| - Do not modify dead-after-return, debug-only, or command-31 FIXME paths. | ||
|
|
||
| --- | ||
|
|
||
| ### Task 1: Prove and register the existing GTID causal workload | ||
|
|
||
| Files: | ||
|
|
||
| - Modify: test/tap/groups/groups.json line 420 | ||
| - Test: test/tap/tests/test_gtid_from_ok-t.cpp | ||
|
|
||
| Interfaces: | ||
|
|
||
| - Consumes: the existing causal min_gtid SELECT workload and MySQL 8.4 group. | ||
| - Produces: GCOV execution of the existing TAP in mysql84-g5. | ||
|
|
||
| - [ ] Step 1: Build the unchanged GTID TAP with GCOV | ||
|
|
||
| ~~~ | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win Add language identifiers to the fenced examples.
Also applies to: 64-64, 79-79, 85-85, 114-114, 124-124, 138-138, 144-144, 157-157, 179-179, 193-193, 207-207, 213-213, 226-226, 244-244, 255-255, 263-263 🧰 Tools🪛 markdownlint-cli2 (0.23.2)[warning] 47-47: Fenced code blocks should have a language specified (MD040, fenced-code-language) 🤖 Prompt for AI AgentsSource: Linters/SAST tools |
||
| git_version=$(git describe --long --abbrev=7) | ||
| git_epoch=$(git show -s --format=%ct HEAD) | ||
| docker compose run --rm --no-deps --entrypoint bash \ | ||
| -e GIT_VERSION_BASE="$git_version" -e GIT_VERSION="$git_version" \ | ||
| -e SOURCE_DATE_EPOCH="$git_epoch" -e WITHGCOV=1 \ | ||
| -w /opt/proxysql ubuntu22_dbg_build -lc ' | ||
| make -j8 WITHGCOV=1 GIT_VERSION_BASE="$GIT_VERSION_BASE" GIT_VERSION="$GIT_VERSION" debug | ||
| make -C test/tap -j8 WITHGCOV=1 GIT_VERSION="$GIT_VERSION" tap | ||
| make -C test/tap/tests -j8 WITHGCOV=1 GIT_VERSION="$GIT_VERSION" test_gtid_from_ok-t | ||
| ' | ||
| ~~~ | ||
|
|
||
| Expected: the existing test binary is built with the same objects used by the MySQL 8.4 GCOV workflow. | ||
|
|
||
| - [ ] Step 2: Run only the existing GTID TAP | ||
|
|
||
| ~~~ | ||
| export INFRA_ID=coverage-gtid-proof | ||
| export TAP_GROUP=mysql84-g5 | ||
| export TEST_PY_TAP_INCL='test_gtid_from_ok-t' | ||
| export COVERAGE=1 | ||
| ./test/infra/control/ensure-infras.bash | ||
| ./test/infra/control/run-tests-isolated.bash | ||
| ~~~ | ||
|
|
||
| Expected: TAP passes and the LCOV report marks the GTID candidate lines in lib/MyHGC.cpp executed. | ||
|
|
||
| - [ ] Step 3: Register the proven workload | ||
|
|
||
| Change the entry to: | ||
|
|
||
| ~~~ | ||
| "test_gtid_from_ok-t" : [ "legacy-binlog-g1", "mysql84-binlog-g1", "mysql84-g5", "mysql90-binlog-g1", "mysql95-binlog-g1" ] | ||
| ~~~ | ||
|
|
||
| - [ ] Step 4: Validate and commit | ||
|
|
||
| ~~~ | ||
| python3 test/tap/groups/lint_groups_json.py | ||
| python3 test/tap/groups/check_groups.py --source | ||
| python3 test/tap/groups/lint_group_coverage.py test/tap/groups/groups.json | ||
| git add test/tap/groups/groups.json | ||
| git commit -m "test: run GTID causal reads in GCOV suite" | ||
| ~~~ | ||
|
|
||
| ### Task 2: Add a deterministic Aurora real-traffic TAP | ||
|
|
||
| Files: | ||
|
|
||
| - Create: test/tap/tests/test_aurora_query_routing-t.cpp | ||
| - Create: test/deps/cluster_simulator/tests/aurora_traffic_payloads/query_routing.json | ||
| - Modify: test/tap/groups/groups.json | ||
| - Test: cluster_sim_aurora-g1 | ||
|
|
||
| Interfaces: | ||
|
|
||
| - Consumes: cluster_sim_runner.h, AURORA_HOSTNAME, AURORA_PORT, the aurora1 user, and the backend-address response from SELECT @@version_comment. | ||
| - Produces: frontend traffic with max_lag_ms=10, an eligible-replica response from 127.0.1.12, an incremented Aurora skip counter, and no writer selection. | ||
|
|
||
| - [ ] Step 1: Write the failing fixture and TAP | ||
|
|
||
| The fixture creates writer host.1.11 at lag 0, replicas host.1.12 at lag 0, | ||
| host.1.13 at lag 4, and host.1.14 at lag 50; it uses a monitor threshold above | ||
| 50 and `aurora_max_lag_ms_only_read_from_replicas=1`. The TAP starts from that | ||
| fixture, connects as aurora1 to the normal frontend, and issues: | ||
|
|
||
| ~~~ | ||
| SELECT @@version_comment LIMIT 1 /* ;max_lag_ms=10;create_new_connection=1 */ | ||
| ~~~ | ||
|
|
||
| It must assert the eligible host.1.13 connection count increases while the | ||
| zero-lag candidate and writer counts do not, and that | ||
| `aws_aurora_replicas_skipped_during_query` increased. | ||
|
|
||
| - [ ] Step 2: Verify red before complete implementation | ||
|
|
||
| ~~~ | ||
| make -C test/tap/tests -j"$(nproc)" WITHGCOV=1 test_aurora_query_routing-t | ||
| ~~~ | ||
|
|
||
| Expected: first the target is absent; after the initial TAP exists but before monitor-state synchronization is implemented, it fails to prove the endpoint and counter. | ||
|
|
||
| - [ ] Step 3: Implement synchronization and assertions | ||
|
|
||
| Use the existing cluster-simulator runner to configure state. Wait for expected runtime_mysql_servers rows instead of a guessed sleep. Read stats_mysql_global with a scalar helper that fails on query/result errors. Consume all resultsets and close admin, control, and frontend connections on every exit path. | ||
|
|
||
| - [ ] Step 4: Register and prove the focused simulator test | ||
|
|
||
| Add: | ||
|
|
||
| ~~~ | ||
| "test_aurora_query_routing-t" : [ "cluster_sim_aurora-g1" ] | ||
| ~~~ | ||
|
|
||
| Run: | ||
|
|
||
| ~~~ | ||
| export INFRA_ID=coverage-aurora-routing | ||
| export TAP_GROUP=cluster_sim_aurora-g1 | ||
| export TEST_PY_TAP_INCL='test_aurora_query_routing-t' | ||
| export COVERAGE=1 | ||
| ./test/infra/control/ensure-infras.bash | ||
| ./test/infra/control/run-tests-isolated.bash | ||
| ~~~ | ||
|
|
||
| Expected: TAP passes and LCOV marks lag filtering and replica-only writer removal in lib/MyHGC.cpp executed. | ||
|
|
||
| - [ ] Step 5: Commit | ||
|
|
||
| ~~~ | ||
| git add test/tap/tests/test_aurora_query_routing-t.cpp test/deps/cluster_simulator/tests/aurora_traffic_payloads/query_routing.json test/tap/groups/groups.json | ||
| git commit -m "test: cover Aurora routing with frontend traffic" | ||
| ~~~ | ||
|
|
||
| ### Task 3: Cover live Admin built-in commands in GCOV CI | ||
|
|
||
| Files: | ||
|
|
||
| - Create: test/tap/tests/test_admin_builtin_coverage-t.cpp | ||
| - Modify: test/tap/groups/groups.json | ||
| - Test: mysql84-g5 | ||
|
|
||
| Interfaces: | ||
|
|
||
| - Consumes: CommandLine admin credentials, PROXYSQLTEST 1/2/3/6/12/13/16, stats_mysql_query_digest, and mysql_query_rules_fast_routing. | ||
| - Produces: behavioral proof of digest snapshot/reset/asynchronous purge and fast-routing generation/load, with runtime state restored. | ||
|
|
||
| - [ ] Step 1: Write the failing Admin TAP | ||
|
|
||
| The test drives: | ||
|
|
||
| ~~~ | ||
| PROXYSQLTEST 1 1 | ||
| PROXYSQLTEST 2 | ||
| PROXYSQLTEST 3 | ||
| PROXYSQLTEST 6 0 | ||
| PROXYSQLTEST 12 64 | ||
| PROXYSQLTEST 13 2 | ||
| PROXYSQLTEST 16 64 | ||
| ~~~ | ||
|
|
||
| It asserts digest rows are populated then reset/purged, command 12 produces 64 non-empty-username rows in config and runtime, and command 16 produces 64 empty-username rows in config and runtime. An RAII guard reloads rules from disk and runtime on all exits. | ||
|
|
||
| - [ ] Step 2: Verify red before complete implementation | ||
|
|
||
| ~~~ | ||
| make -C test/tap/tests -j"$(nproc)" WITHGCOV=1 test_admin_builtin_coverage-t | ||
| ~~~ | ||
|
|
||
| Expected: first the target is absent; the initial test fails if an expected postcondition is missing, rather than merely accepting command success. | ||
|
|
||
| - [ ] Step 3: Implement async-purge polling and cleanup | ||
|
|
||
| Poll stats_mysql_query_digest with a bounded timeout after command 6. Check mysql_affected_rows for commands 12 and 16 and query both config and runtime fast-routing tables. Cleanup runs before closing the admin connection. | ||
|
|
||
| - [ ] Step 4: Register and run in the GCOV group | ||
|
|
||
| Add: | ||
|
|
||
| ~~~ | ||
| "test_admin_builtin_coverage-t" : [ "mysql84-g5" ] | ||
| ~~~ | ||
|
|
||
| Run: | ||
|
|
||
| ~~~ | ||
| export INFRA_ID=coverage-admin-builtins | ||
| export TAP_GROUP=mysql84-g5 | ||
| export TEST_PY_TAP_INCL='test_admin_builtin_coverage-t' | ||
| export COVERAGE=1 | ||
| ./test/infra/control/ensure-infras.bash | ||
| ./test/infra/control/run-tests-isolated.bash | ||
| ~~~ | ||
|
|
||
| Expected: TAP passes and LCOV includes cases 2, 3, 6, 12, 13, and 16 in lib/ProxySQL_Admin_Tests2.cpp. | ||
|
|
||
| - [ ] Step 5: Commit | ||
|
|
||
| ~~~ | ||
| git add test/tap/tests/test_admin_builtin_coverage-t.cpp test/tap/groups/groups.json | ||
| git commit -m "test: cover live admin built-in commands" | ||
| ~~~ | ||
|
|
||
| ### Task 4: Final verification and coverage evidence | ||
|
|
||
| Files: | ||
|
|
||
| - Verify: all changes from Tasks 1-3. | ||
|
|
||
| Interfaces: | ||
|
|
||
| - Consumes: focused TAP outputs and generated LCOV reports. | ||
| - Produces: evidence that every new or re-registered test reaches its intended production path. | ||
|
|
||
| - [ ] Step 1: Validate repository state | ||
|
|
||
| ~~~ | ||
| git diff origin/v3.0...HEAD --check | ||
| python3 test/tap/groups/lint_groups_json.py | ||
| python3 test/tap/groups/check_groups.py --source | ||
| python3 test/tap/groups/lint_group_coverage.py test/tap/groups/groups.json | ||
| ~~~ | ||
|
|
||
| Expected: no whitespace errors, valid JSON, and no group-registration failure. | ||
|
|
||
| - [ ] Step 2: Inspect focused coverage | ||
|
|
||
| ~~~ | ||
| rg -n 'MyHGC\.cpp|ProxySQL_Admin_Tests2\.cpp' ci_infra_logs/*/coverage-report/*.info | ||
| ~~~ | ||
|
|
||
| Expected: GTID/Aurora reports contain their MyHGC.cpp paths and the Admin report contains the live switch cases. | ||
|
|
||
| - [ ] Step 3: Confirm final diff | ||
|
|
||
| ~~~ | ||
| git status --short | ||
| git diff --check | ||
| ~~~ | ||
|
|
||
| Expected: only intentional coverage changes and documentation commits are present. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🔒 Security & Privacy | 🟠 Major | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
Repository: sysown/proxysql
Length of output: 2014
🏁 Script executed:
Repository: sysown/proxysql
Length of output: 2014
🌐 Web query:
site:github.com/sysown/proxysql "CI-mysql84-binlog-g1.yml"💡 Result:
CI-mysql84-binlog-g1.yml is a configuration file associated with the ProxySQL open-source project's continuous integration (CI) infrastructure [1][2]. It is used to define and execute automated tests specifically for MySQL 8.4 environments that utilize binlog (binary log) replication features [1][2]. Key details regarding this file and its context include: Purpose: It serves as part of a specialized test suite for verifying ProxySQL's interaction with MySQL 8.4 binlog replication [1][2]. This includes managing the underlying infrastructure, such as Docker containers, orchestrator services, and specific MySQL configurations required for binlog testing [1][2]. Context within ProxySQL CI: - Infrastructure: It is linked to the infra-mysql84-binlog test infrastructure, which includes components like ProxySQL, MySQL 8.4 nodes, and binlog reader services [1][2]. - Integration: The file is used alongside other CI workflows (such as CI-mysql84-g1 through CI-mysql84-g5) to ensure comprehensive test coverage [3][4]. - Recent Updates: As of early 2026, the ProxySQL project has undergone significant CI migration, involving the creation of new MySQL 8.4 test groups and the refinement of binlog-specific testing to better support modern MySQL versions [1][2][5]. If you are looking for the file's content or specific configuration, it is part of the ProxySQL GitHub repository under the.github/workflows/ directory [6][3]. These workflows typically inherit secrets and utilize reusable actions to run TAP (Test Anything Protocol) tests across different environments [6][1][4].
Citations:
infra-mysql57-binlogandinfra-mysql84-binlog#5591🌐 Web query:
site:github.com/sysown/proxysql "ci-mysql84-binlog-g1.yml"💡 Result:
ci-mysql84-binlog-g1.yml is a configuration file used within the ProxySQL continuous integration (CI) architecture, specifically within the sysown/proxysql GitHub repository [1][2]. It is part of a dedicated infrastructure setup for testing MySQL 8.4 binlog replication functionalities [3][4]. Key details regarding this file and its context include: Purpose: It defines a reusable workflow environment or configuration for running specific automated test suites (TAP tests) related to MySQL 8.4 binlog reader and replication features [3][4]. CI Infrastructure: The file is associated with the infra-mysql84-binlog directory, which includes Docker-based testing infrastructure [3][4]. This infrastructure supports testing scenarios such as binlog fast-forward, multi-backend crash recovery, and binlog reader hostgroup routing [4]. Workflow Integration: Within the repository's GitHub Actions architecture, caller workflows (such as CI-mysql84-g1.yml) trigger these reusable workflows to execute specific test groups [5][6]. The migration to dedicated reusable workflows like ci-mysql84-binlog-g1.yml (often managed via the GH-Actions branch) allows for more granular control over the CI test execution chain [2][6]. Relationship to Test Groups: The mysql84-binlog-g1 group is referenced in configuration files like groups.json to assign relevant test cases—such as tests for binlog dumps and fast-forward mechanisms—to this specific testing environment [4].
Citations:
infra-mysql57-binlogandinfra-mysql84-binlog#5591🌐 Web query:
GitHub Actions workflow_run event security untrusted code write permissions secrets documentation💡 Result:
The workflow_run event in GitHub Actions is a powerful but potentially dangerous trigger that can lead to privilege escalation and security compromises if not handled correctly [1][2][3]. Because this event runs with elevated privileges—including write access to the repository and access to stored secrets—it is frequently targeted by attackers who submit malicious pull requests to trigger these workflows [4][2][5]. Key Security Risks: - Privilege Escalation: Even if the initial workflow (the one that triggers the workflow_run) is unprivileged, the downstream workflow triggered by workflow_run may automatically receive elevated permissions and secret access, allowing code to execute with higher authority [5][3]. - Untrusted Artifacts: Artifacts generated by the triggering (upstream) workflow should be treated as untrusted. If a privileged workflow downloads and uses these artifacts (e.g., executing binaries or scripts contained within them), it can result in arbitrary code execution [4][2][6]. - Checkout Vulnerabilities: A common exploit pattern involves the downstream workflow checking out code using the commit SHA of the untrusted pull request (
github.event.workflow_run.head_sha). If this code is then built or executed, the attacker effectively gains control of the privileged runner [5]. Best Practices for Secure Implementation: - Isolate Untrusted Code: Handle untrusted pull requests via the unprivileged pull_request trigger [7][4]. The workflow processing the PR should only perform build/test tasks, store results in artifacts, and exit [7][4]. - Strictly Filter Triggers: Do not allow workflow_run to trigger for all workflows in your repository. Use filters to specify exact workflow names, target branches, and require a successful conclusion (github.event.workflow_run.conclusion == 'success') [3][6]. - Minimize Permissions: Explicitly set permissions for the GITHUB_TOKEN at the job level using the permissions key. Start with an empty object (permissions: {}) and grant only the absolute minimum read or write access required [2][8][9]. - Validate Artifacts: Never assume artifacts from a previous workflow are safe. If your privileged workflow must consume them, verify their integrity (e.g., checksums or signatures) before execution [4][6]. - Prefer Alternatives: When possible, replace complex chains involving workflow_run with workflow_call to use reusable workflows, which provide more explicit control over execution and secrets [2][6].Citations:
🌐 Web query:
site:github.com/sysown/proxysql/pull/5598 "CI-mysql84-binlog-g1" "head_sha"💡 Result:
The term CI-mysql84-binlog-g1 head_sha refers to a specific technical configuration challenge encountered within the ProxySQL continuous integration (CI) architecture [1]. In the context of GitHub Actions workflows for ProxySQL, developers identified issues with workflow_run head_sha propagation [1]. Specifically, there was a documented incident—referred to as the 78b8f5a incident—related to how the head_sha is handled when triggering dependent workflows or utilizing reusable workflows for MySQL 8.4 testing suites [1]. This issue necessitated architectural changes in how ProxySQL manages its CI pipelines, leading to the migration of legacy and MySQL 8.4 CI callers to dedicated reusable workflows to ensure proper SHA pinning and execution context [1].
Citations:
🌐 Web query:
site:github.com/sysown/proxysql/pull/5598 "secrets: inherit" "write-all"💡 Result:
There is no single GitHub Actions configuration syntax defined as secrets: inherit write-all. These are two distinct features in GitHub Actions that serve different purposes: secrets: inherit This syntax is used when calling a reusable workflow. It allows the caller workflow to pass all of its secrets to the called reusable workflow, eliminating the need to explicitly map each secret individually. permissions: write-all This is a deprecated or discouraged setting used to grant a workflow or job permission to write to all available scopes (e.g., contents, packages, issues). GitHub strongly recommends using the principle of least privilege by specifying only the granular permissions required for the job, rather than using write-all. While these two can appear in the same workflow file, they control entirely different aspects of security: secrets: inherit manages the propagation of sensitive environment variables to reusable workflows, while permissions manage the authorization scopes for the workflow's interaction with the GitHub API.
Citations:
🌐 Web query:
site:github.com/sysown/proxysql/pull/5591 "ci-mysql84-binlog-g1.yml" "workflow_run"💡 Result:
The ci-mysql84-binlog-g1.yml file appears to be a GitHub Actions workflow configuration used in the ProxySQL repository (sysown/proxysql) to orchestrate continuous integration testing for MySQL 8.4 binlog-related features [1][2]. While the exact filename ci-mysql84-binlog-g1.yml may be a reference to the group-based CI infrastructure rather than a single static file (as many similar workflows are generated or named according to test groups like mysql84-g1 or mysql84-binlog-g1), the workflow_run pattern is a standard component of the repository's CI pipeline [3][2]. Key details regarding this workflow pattern include: - Purpose: It gates downstream test workflows on the successful completion of a trigger workflow, typically named CI-trigger [3][4][5]. - Trigger Mechanism: The workflow uses the workflow_run event, configured with types: [completed] [3]. This ensures that resource-intensive test suites (like those for MySQL 8.4 binlog testing) only execute if the preceding CI-trigger job succeeds [6]. - Implementation Pattern: The workflows follow a consistent template where the jobs are defined to run only if github.event.workflow_run.conclusion == 'success' [3][4]. This architecture is used extensively across the repository to manage parallel test groups, such as legacy-g*, mysql84-, and mysql84-gr- [7][2][6]. - Context: The mysql84-binlog-g1 identifier specifically relates to the infrastructure introduced to test binlog dump, fast-forward, and reader functionality using MySQL 8.4 [1][2]. This infrastructure includes specific Docker configurations and environment variables to support the proxysql-mysqlbinlog reader [1][2]. In summary, workflow_run is used in these CI files to create a dependency chain, ensuring that test groups defined as mysql84-binlog-g1 are executed reliably and conditionally based on the outcome of the repository's trigger workflow [3][2][6].
Citations:
infra-mysql57-binlogandinfra-mysql84-binlog#5591gh run delete, blocking downstream test workflows #5811🌐 Web query:
site:github.com/sysown/proxysql/blob/GH-Actions/.github/workflows/ci-mysql84-binlog-g1.yml💡 Result:
The specified GitHub workflow file was not found; the URL returns 404 Not Found. ()
Repository:
sysown/proxysql(github.com)Citations:
🌐 Web query:
site:github.com/sysown/proxysql/pull/5598 "78b8f5ac"💡 Result:
The identifier 78b8f5a refers to a specific incident mentioned in the documentation for ProxySQL, an open-source high-performance MySQL proxy [1]. Specifically, it is cited in a GitHub pull request (
#5598) as the "78b8f5ac6 incident," which pertains to issues regarding head_sha propagation in GitHub Actions workflows [1]. The incident highlights common pitfalls in CI architecture, particularly concerning how workflows using the workflow_run trigger handle SHA propagation when calling reusable workflows [1].Citations:
🌐 Web query:
site:github.com/sysown/proxysql/pull/5598 "triggering SHA"💡 Result:
In the context of CI/CD and software development, particularly with GitHub Actions, triggering SHA refers to the specific commit hash (SHA) that initiated a workflow run [1]. When a workflow is triggered by an event such as a pull request or push, the system identifies the exact state of the repository at that moment using a SHA identifier. In more complex CI configurations involving chained workflows—such as those using the workflow_run trigger—the triggering SHA often refers to the head_sha of the workflow that initiated the current one [1]. Ensuring the correct propagation of this head_sha is critical in CI architecture to maintain consistency between caller and reusable workflows, as errors in this process can lead to deployment or testing failures [1].
Citations:
🌐 Web query:
site:github.com/sysown/proxysql/pull/5598 "checkout" "workflow_run"💡 Result:
When using the workflow_run event in GitHub Actions, the workflow is triggered by the completion of another workflow, and it does not automatically check out the code from the repository in the same way as a push or pull_request event. To check out the specific source code that triggered the original workflow, you must explicitly pass the head_sha from the triggering workflow context to the actions/checkout action [1]. You can achieve this by using the following configuration in your workflow: - uses: actions/checkout@v4 with: ref: ${{ github.event.workflow_run.head_sha }} This ensures that the checkout action fetches the exact commit that was being processed by the workflow that triggered the current one [1]. Failing to specify the ref will result in the checkout action defaulting to the branch or tag where the workflow file is located, which may not match the commit that initiated the triggering workflow [1].
Citations:
🌐 Web query:
site:github.com/sysown/proxysql/pull/5590 "CI-mysql84-binlog-g1"💡 Result:
The term CI-mysql84-binlog-g1 is a reference to a specific continuous integration (CI) test configuration used within the ProxySQL project [1]. It corresponds to a workflow file, CI-mysql84-g1.yml, which is part of a suite of automated workflows (CI-mysql84-g1 through CI-mysql84-g5) designed to test ProxySQL compatibility with MySQL 8.4 [1]. In this context, g1 signifies the first "test group" in a series of segmented test suites [1]. The configuration is managed by the project's CI system, which uses a groups.json file to map specific tests—including those involving binary logs (binlog)—to these numbered groups to organize and execute the test suite efficiently [1]. The identifier is specific to the internal repository structure of the sysown/proxysql project and is not a standard MySQL configuration parameter [1].
Citations:
🌐 Web query:
site:github.com/sysown/proxysql ".github/workflows/CI-trigger.yml" "pull_request"💡 Result:
The file.github/workflows/CI-trigger.yml is a specific workflow configuration file used in the ProxySQL project (sysown/proxysql) to manage their Continuous Integration (CI) process [1][2]. In this specific implementation, the pull_request trigger is configured to execute the workflow whenever a pull request is opened or updated, while explicitly ignoring changes to certain files (such as documentation and internal GitHub workflow files) to optimize CI usage [2][3]: on: pull_request: paths-ignore: - '.github/' - '.md' The primary purpose of this CI-trigger workflow is to serve as an anchor for the pull request's head_sha and to coordinate downstream CI tasks [1]. Instead of running heavy build tasks directly, this workflow acts as a gateway that blocks until other build workflows (e.g., CI-builds.yml) complete [1]. By doing so, it ensures that subsequent workflows—which may trigger on the completion of this one—can rely on a stable build state and the correct commit SHA associated with the pull request [1]. In summary, this file is a specialized orchestrator used in a larger CI pipeline to manage build sequencing and state tracking for pull requests in the ProxySQL repository [1][2].
Citations:
🌐 Web query:
site:github.com/sysown/proxysql "CI-trigger" "workflow_run" "pull_request"💡 Result:
The term CI-trigger in the context of workflow_run and pull_request typically refers to a design pattern used to bridge the limitations of the GitHub Actions workflow_run trigger [1][2]. Key technical aspects include: 1. The Limitation: Workflows triggered by workflow_run execute in the context of the default branch and do not natively have access to the pull request's HEAD commit SHA or context [2][3]. They instead receive information based on the workflow run that triggered them [2]. 2. The Pattern: A CI-trigger workflow is configured to run on pull_request events [1][2]. Because it is triggered directly by the pull request, it correctly identifies the PR's head_sha [1][2]. Its sole purpose is often to anchor this context and, if necessary, wait for other build processes to complete using tools like gh run watch [1][2]. 3. Orchestration: Once the CI-trigger workflow completes, subsequent workflows configured with workflow_run: workflows: [ CI-trigger ] will execute [1][2]. This allows these downstream workflows to perform tasks (such as integration testing or reporting) while being aware of the original PR's context, as they are chained to the workflow that successfully captured it [1][2]. This pattern is primarily used to ensure that CI pipelines are testing the actual code submitted in a pull request rather than the state of the default branch [2].
Citations:
🌐 Web query:
site:github.com/sysown/proxysql "github.event.workflow_run.head_sha" "actions/checkout"💡 Result:
When working with the workflow_run event in GitHub Actions, github.event.workflow_run.head_sha refers to the SHA of the commit that triggered the upstream workflow [1]. Because a workflow_run event executes in the context of the default branch, checking out the code directly without specifying a reference will result in checking out the HEAD of the default branch, rather than the commit that actually initiated the CI process [1]. To correctly checkout the code associated with the triggering event, you must explicitly pass the head_sha to the actions/checkout action. This is commonly implemented by storing the SHA in an environment variable or passing it directly to the ref input [1][2]. Example implementation: env: SHA: ${{ github.event.workflow_run && github.event.workflow_run.head_sha || github.sha }} jobs: ci: runs-on: ubuntu-latest steps: - name: Checkout repository uses: actions/checkout@v4 with: ref: ${{ env.SHA }} In this pattern, the conditional logic ensures that if the workflow is triggered by workflow_run, it uses the head_sha of the upstream event; otherwise, it defaults to the current job's sha [1][3][2]. This approach is essential for scenarios like maintaining cache consistency or running tests against the specific commit intended for validation [1][4][5].
Citations:
🌐 Web query:
site:github.com/sysown/proxysql "permissions: write-all" "CI-mysql84"💡 Result:
The term write-all in the context of CI-mysql84 refers to a specific configuration or permission scope used within ProxySQL's continuous integration testing infrastructure, rather than a standard MySQL permission. Evidence from ProxySQL development repositories indicates that CI-mysql84 refers to a series of automated test environments (CI workflows) used to validate ProxySQL against MySQL 8.4 [1][2]. In these environments, various user privileges and configurations are tested, sometimes resulting in noise such as Access denied errors when the monitor user lacks necessary privileges like SUPER or SLAVE MONITOR [1]. There is no standard MySQL privilege named write-all. If you are seeing this term in an error message or configuration file associated with your CI setup, it is likely an internal identifier for: 1. A custom test user or permission profile defined specifically for the CI-mysql84 test suite. 2. An abstraction in a CI script (such as a GitHub Action or shell script) intended to grant broad write permissions to a test database or environment. To resolve issues related to this, it is recommended to: - Check the repository's CI configuration files (e.g.,.github/workflows/CI-mysql84-*.yml) to see how the test user is initialized. - Verify the grants assigned to the user running the tests on the MySQL 8.4 backend [1]. - Review documentation or internal scripts that define the CI environment setup for the specific test suite.
Citations:
gh run delete, blocking downstream test workflows #5811Separate untrusted test execution from privileged Codecov upload.
When
CI-triggersucceeds for a pull request, thisworkflow_runcaller checks out and executes the triggering SHA withwrite-alland inherited secrets. A pull request can therefore run attacker-controlled code with repository write permissions and inherited credentials.Use an unprivileged job for triggering-SHA tests. Run Codecov upload from a trusted ref or isolated privileged job. Grant only the required permissions, such as
id-token: writeand necessary read access. Pass named secrets instead ofsecrets: inherit. Update the caller, design specification, and plan to document this trust boundary.🧰 Tools
🪛 zizmor (1.29.0)
[error] 19-19: overly broad permissions (excessive-permissions): uses write-all permissions
(excessive-permissions)
[warning] 20-20: secrets unconditionally inherited by called workflow (secrets-inherit): this reusable workflow
(secrets-inherit)
📍 Affects 3 files
.github/workflows/CI-mysql84-binlog-g1.yml#L16-L21(this comment).github/workflows/CI-mysql84-binlog-g1.yml#L4-L8docs/superpowers/specs/2026-08-15-mysql84-binlog-g1-coverage-design.md#L14-L18docs/superpowers/plans/2026-08-15-mysql84-binlog-g1-coverage.md#L42-L48🤖 Prompt for AI Agents
Sources: MCP tools, Linters/SAST tools