-
Notifications
You must be signed in to change notification settings - Fork 1.1k
test(pg-compat): SP-1..SP-3 combined — PG protocol coverage, polyglot foundation, driver matrix (supersedes #5894, #5903, #5910) #6020
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
61dbcf8
69b3675
23c18ac
1d045a2
519e311
debf333
8885713
1bb7144
0a421b5
8751dbf
3a51d03
86d4448
e90633a
6db3321
07c2ff7
a005a86
60e6ce0
8a5a6c6
5cb2abc
f220a70
f7e04e7
c4926e1
c8cc4e6
218e552
230fbea
f738a40
09336ac
080f783
b4b811f
96316bf
a3f91dd
fb5ce59
5e84354
1745a9d
a95fa02
2085044
9f819e6
4bd0f37
feaab3a
e0cdcea
da7c6a1
4cfeaba
5295364
d167731
45b34d0
acd6f0b
4db6cb4
dde05c6
db359ee
8d2f338
f26787b
04cce6b
8859ee4
26fc586
0be6b4b
79438d0
c1fb385
ba207ea
a9e0a67
f66297e
97128b1
38a13fb
310e9c2
8ef2264
8de370b
afac510
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,47 @@ | ||
| # PAIRED FILE -- caller half of the CI-pg-compat pair (lives on v3.0). The | ||
| # reusable half, .github/workflows/gh-actions-reusable/ci-pg-compat.yml, is | ||
| # staged in THIS repo for review but must be merged to the `GH-Actions` | ||
| # branch FIRST, at path `.github/workflows/ci-pg-compat.yml`, before (never | ||
| # after) this caller file merges to v3.0 -- see doc/GH-Actions/README.md | ||
| # "Merge order" (~line 816): `workflow_run`/`workflow_call` references are | ||
| # only resolved against files that already exist on the target branch, so a | ||
| # caller landing before its reusable exists on GH-Actions fails immediately | ||
| # with "Unable to resolve action". See doc/GH-Actions/README.md (~lines | ||
| # 42-170) for the full two-branch caller/reusable split rationale. | ||
| name: CI-pg-compat | ||
|
|
||
| on: | ||
| schedule: | ||
| - cron: '0 3 * * *' | ||
| pull_request: | ||
| types: [opened, synchronize, reopened, labeled] | ||
| workflow_dispatch: | ||
|
|
||
| concurrency: | ||
| group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref_name }} | ||
| cancel-in-progress: true | ||
|
|
||
| jobs: | ||
| pg-compat: | ||
| # Runs on: the nightly schedule, a manual dispatch, or a pull_request | ||
| # that carries the 'pg-compat' label (checked on every listed pull_request | ||
| # type, including 'labeled', so adding the label to an already-open PR | ||
| # triggers a run without needing a new commit). Unlike the TAP families, | ||
| # this does NOT chain off CI-trigger/CI-builds -- it builds ProxySQL | ||
| # inline in the reusable job, so it doesn't need CI-builds' cache to | ||
| # exist first (nightly/label runs have no guaranteed prior CI-builds run | ||
| # to restore from). | ||
| if: >- | ||
| github.event_name == 'schedule' || | ||
| github.event_name == 'workflow_dispatch' || | ||
| contains(github.event.pull_request.labels.*.name, 'pg-compat') | ||
| # write-all: reusable-workflow permissions are the intersection of | ||
| # caller + callee: the callee at ci-pg-compat.yml@GH-Actions also | ||
| # declares write-all (needed for actions/upload-artifact's write scope | ||
| # under the pull_request event, matching CI-3p-postgresql.yml's | ||
| # documented rationale). | ||
| permissions: write-all # NOSONAR githubactions:S8234 — see the note above; matches all other caller workflows | ||
| uses: sysown/proxysql/.github/workflows/ci-pg-compat.yml@GH-Actions # NOSONAR githubactions:S7637 — branch ref matches all other caller workflows | ||
| secrets: inherit # NOSONAR githubactions:S7635 — matches all other caller workflows | ||
| with: | ||
| trigger: ${{ toJson(github) }} | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,165 @@ | ||
| # STAGED FILE -- this is the reusable half of the CI-pg-compat pair. | ||
| # It is authored here (on v3.0, under gh-actions-reusable/) for review, but | ||
| # it does NOT run from here. It must be merged to the `GH-Actions` branch | ||
| # at path `.github/workflows/ci-pg-compat.yml` FIRST, before (or in the same | ||
| # merge window as, but not after) the caller `.github/workflows/CI-pg-compat.yml` | ||
| # lands on `v3.0` -- see doc/GH-Actions/README.md "Merge order" (~line 816): | ||
| # a caller referencing `ci-pg-compat.yml@GH-Actions` before that file exists | ||
| # on GH-Actions fails immediately with "Unable to resolve action". See the | ||
| # two-branch caller/reusable split explained in doc/GH-Actions/README.md | ||
| # (~lines 42-170): callers (`CI-*.yml`, uppercase) live on `v3.0`; reusables | ||
| # (`ci-*.yml`, lowercase) live on `GH-Actions`. | ||
| name: CI-pg-compat | ||
|
|
||
| on: | ||
| workflow_dispatch: | ||
| workflow_call: | ||
| inputs: | ||
| trigger: | ||
| type: string | ||
|
|
||
| # No env.SHA/trigger-JSON parsing here (unlike the workflow_run-triggered | ||
| # reusables, e.g. ci-legacy-g4.yml): those need it because their caller is | ||
| # invoked BY workflow_run, whose own github.sha is the default branch tip, | ||
| # not the real source commit -- the real sha only exists inside the passed | ||
| # `trigger` JSON. This caller triggers directly via pull_request/schedule/ | ||
| # workflow_dispatch, so github.sha here (a workflow_call callee inherits the | ||
| # caller's context) already IS the right commit; `inputs.trigger` is kept | ||
| # only for parity with the sibling callers' `with: trigger: ...` shape and | ||
| # isn't parsed for a sha. checkout below uses actions/checkout@v4's default | ||
| # ref (the triggering ref), so no untrusted github.event.* field is ever | ||
| # substituted into a `ref:`. | ||
|
|
||
| jobs: | ||
| pg-compat: | ||
| runs-on: ubuntu-22.04 | ||
| # Generous budget: a from-scratch `PROXYSQL31=1 make debug` (deps -> lib | ||
| # -> src) on a 2-core GH-hosted runner is the dominant cost here (there | ||
| # is no build-cache restore in this job, unlike the CI-builds-fed TAP | ||
| # families -- this suite runs inline, like the CI-3p-* family, since its | ||
| # schedule/label triggers have no guaranteed prior CI-builds run to | ||
| # restore a cache from). | ||
| timeout-minutes: 120 | ||
| permissions: write-all | ||
| steps: | ||
| - name: Checkout | ||
| uses: actions/checkout@v4 | ||
| with: | ||
| # This job only builds and tests; it never pushes. Leaving the job's | ||
| # write-all token persisted in .git/config would expose it to every | ||
| # subsequent step, including the third-party driver images this suite | ||
| # builds and runs. | ||
| persist-credentials: false | ||
|
|
||
| # Inline build (CI-3p-* model, not the CI-trigger/CI-builds cache-chain | ||
| # model used by the TAP families): no ccache pattern exists elsewhere | ||
| # in this repo's workflows (checked both branches) to reuse, so this | ||
| # is a plain build for v1. PROXYSQL31=1 is required -- bare `make` | ||
| # would leave FFTO/TSDB symbols out and is not what any tier actually | ||
| # ships; debug is required because the isolated harness | ||
| # (start-proxysql-isolated.bash / ensure-infras.bash) issues | ||
| # debug-only admin commands. | ||
| - name: Build ProxySQL (debug, PROXYSQL31) | ||
| run: PROXYSQL31=1 make -j$(nproc) debug | ||
|
Comment on lines
+62
to
+63
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.
On a fresh Useful? React with 👍 / 👎. |
||
|
|
||
| # start-proxysql-isolated.bash runs ProxySQL (and its filesystem helpers) | ||
| # from the LOCAL-ONLY tag `proxysql-ci-base:latest`, which nothing on a | ||
| # fresh runner provides -- without this step infra startup dies before a | ||
| # single pg-compat test runs. Every sibling TAP workflow pulls the image | ||
| # from GHCR and retags it; this mirrors ci-legacy-g4.yml, retry loop | ||
| # included, because both the login and the pull have been observed to | ||
| # fail transiently with a client timeout. | ||
| - name: Log in to GHCR and pull CI base image | ||
| env: | ||
| GHCR_USER: ${{ github.actor }} | ||
| GHCR_TOKEN: ${{ secrets.GITHUB_TOKEN }} | ||
| run: | | ||
| set +e | ||
| attempt=0 | ||
| max_attempts=5 | ||
| while [ $attempt -lt $max_attempts ]; do | ||
| attempt=$((attempt + 1)) | ||
| echo ">>> GHCR login+pull attempt ${attempt}/${max_attempts}" | ||
| if echo "$GHCR_TOKEN" | docker login ghcr.io \ | ||
| -u "$GHCR_USER" --password-stdin \ | ||
| && docker pull ghcr.io/sysown/proxysql-ci-base:latest; then | ||
| echo ">>> GHCR login+pull OK on attempt ${attempt}" | ||
| docker tag ghcr.io/sysown/proxysql-ci-base:latest \ | ||
| proxysql-ci-base:latest | ||
| exit 0 | ||
| fi | ||
| if [ $attempt -lt $max_attempts ]; then | ||
| sleep_for=$((attempt * 10)) | ||
| echo ">>> attempt ${attempt} failed; sleeping ${sleep_for}s" | ||
| sleep $sleep_for | ||
| fi | ||
| done | ||
| echo ">>> all ${max_attempts} GHCR attempts failed" | ||
| exit 1 | ||
|
|
||
| # Stand up the pg-compat infra: dbdeployer PG17 primary+2-replica | ||
| # backend, Toxiproxy sidecar, and the ProxySQL container built above | ||
| # (ensure-infras.bash starts ProxySQL itself via | ||
| # start-proxysql-isolated.bash if it isn't already running -- see | ||
| # test/infra/control/ensure-infras.bash step 2). Never manage Docker | ||
| # by hand here; this script is the only supported entry point. | ||
| - name: Stand up infra (backends + Toxiproxy + ProxySQL) | ||
| env: | ||
| INFRA_ID: ci-${{ github.run_id }} | ||
| WORKSPACE: ${{ github.workspace }} | ||
| TAP_GROUP: pg-compat | ||
| run: test/infra/control/ensure-infras.bash | ||
|
|
||
| # Non-gating (discovery phase, spec sec 2.1): the suite's job right now | ||
| # is to build a failure inventory in xfail.toml, not to be all-green. | ||
| # `|| true` keeps this step (and therefore the job) from failing the | ||
| # workflow on real/uncatalogued divergences during discovery. Promote | ||
| # to gating by dropping `|| true` (and tightening xfail.toml) once the | ||
| # suite is green and stable -- see test/pg-compat/README.md. | ||
| # | ||
| # --junitxml path: run-pg-compat.bash's container runs with --rm, so a | ||
| # report written to the container's own filesystem (e.g. /tmp) would | ||
| # be destroyed on exit and never reach this runner -- traced and fixed | ||
| # in run-pg-compat.bash, which now bind-mounts a host directory | ||
| # (default "${WORKSPACE}/pg-compat-reports", override via | ||
| # PGCOMPAT_REPORT_DIR) to /pg-compat-reports inside the container. | ||
| # Writing the report there is what makes it visible to the upload | ||
| # step below. | ||
| - name: Run pg-compat suite (non-gating, discovery phase) | ||
| env: | ||
| INFRA_ID: ci-${{ github.run_id }} | ||
| WORKSPACE: ${{ github.workspace }} | ||
| run: test/pg-compat/run-pg-compat.bash --junitxml=/pg-compat-reports/pg-compat.xml -rxX || true | ||
|
|
||
| # The pg-compat container's default user is root, so the bind-mounted | ||
| # report directory is root-owned on the host afterwards; chown it back | ||
| # to the runner user before upload-artifact (which runs as the | ||
| # non-root runner account) tries to read it. Same pattern already | ||
| # used for docker-written logs in ci-3p-postgresql.yml. | ||
| - name: Fix report ownership | ||
| if: always() | ||
| run: sudo chown -R "$(id -u):$(id -g)" "${{ github.workspace }}/pg-compat-reports" || true | ||
|
|
||
| - name: Publish report | ||
| if: always() | ||
| uses: actions/upload-artifact@v4 | ||
| with: | ||
| name: pg-compat-report | ||
| path: ${{ github.workspace }}/pg-compat-reports/pg-compat.xml | ||
| if-no-files-found: warn | ||
|
|
||
| # Teardown always runs, mirroring ci-legacy-g4.yml's cleanup step: | ||
| # stop the ProxySQL container first, then tear down the backend + | ||
| # Toxiproxy infra. destroy-infras.bash is test/infra/control's | ||
| # documented teardown entry point (paired with ensure-infras.bash). | ||
| - name: Cleanup | ||
| if: always() | ||
| env: | ||
| INFRA_ID: ci-${{ github.run_id }} | ||
| WORKSPACE: ${{ github.workspace }} | ||
| TAP_GROUP: pg-compat | ||
| run: | | ||
| set +e | ||
| docker logs "proxysql.${INFRA_ID}" 2>&1 | tail -50 || true | ||
| test/infra/control/stop-proxysql-isolated.bash | ||
| test/infra/control/destroy-infras.bash | ||
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 | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
Repository: sysown/proxysql
Length of output: 3760
🏁 Script executed:
Repository: sysown/proxysql
Length of output: 3222
🏁 Script executed:
Repository: sysown/proxysql
Length of output: 2732
🌐 Web query:
GitHub Actions reusable workflows permissions inherit secrets inherit writable-GITHUB_TOKEN permission💡 Result:
In GitHub Actions, you can manage secrets and GITHUB_TOKEN permissions for reusable workflows using specific configurations to ensure secure and efficient automation. Secrets To pass secrets from a caller workflow to a reusable workflow, you can use the secrets: inherit keyword [1][2]. When you use this keyword, all secrets defined at the repository or organization level in the caller's environment become available to the called workflow [3]. This simplifies the process compared to passing secrets individually [2]. Note that environment secrets cannot be passed via workflow_call; if you define an environment in a job within the reusable workflow, that environment's secrets will be used instead [4][5]. GITHUB_TOKEN Permissions Permissions for the GITHUB_TOKEN are governed by the following rules: 1. Default Permissions: If you do not explicitly define the permissions key in the caller job, the called reusable workflow will operate with the default GITHUB_TOKEN permissions [6][7]. 2. Downgrading Only: Permissions for the GITHUB_TOKEN passed from a caller workflow to a reusable workflow can only be downgraded, never elevated [6][7]. For example, if a chain of workflows exists (A > B > C), workflow B and C cannot have higher permissions than workflow A [7][8]. 3. Explicit Configuration: It is considered a best practice to explicitly define the permissions key at the workflow or job level in the calling workflow to ensure the reusable workflow has only the minimum access required [3][7][9]. Summary You do not need an explicit inherit keyword for permissions as you do for secrets; permissions are naturally constrained by the caller [6][7]. By using secrets: inherit and explicitly setting restrictive permissions in your caller job, you can effectively control the access level of your reusable workflows [10][3].
Citations:
Reduce the reusable workflow trust boundary.
This caller exposes
write-allGitHub permissions and all caller secrets tosysown/proxysql/.github/workflows/ci-pg-compat.yml@GH-Actions, which is a mutable branch ref. If an update to that branch is accepted, it can run with these capabilities from the scheduled and manual dispatch paths. Pin the workflow to a reviewed full commit SHA, define only the required permissions, and pass only the named secrets the reusable job needs.🧰 Tools
🪛 zizmor (1.29.0)
[error] 43-43: overly broad permissions (excessive-permissions): uses write-all permissions
(excessive-permissions)
[warning] 44-44: secrets unconditionally inherited by called workflow (secrets-inherit): this reusable workflow
(secrets-inherit)
🤖 Prompt for AI Agents
Source: Linters/SAST tools