Repository navigation
ci: point BQ Testing at the google-cloud-python monorepo - #65
Merged
Merged
Conversation
googleapis/python-bigquery-magics was archived in March 2026 and is frozen
at bigquery-magics 0.12.1. Its unit tests no longer pass against the latest
google-cloud-bigquery (3.45.x), which pip resolves at install time because
the dependency is unpinned (<4.0.0,>=3.13.0):
* test_bigquery_magic_with_bqstorage_from_argument: the user agent now
has extra "legacy-gcb/<ver> pandas-gbq/<ver>" tokens appended.
* test_bigquery_magic_query_variable_not_identifier: the
TableReference.from_string error message was reworded.
Both tests are already fixed upstream in the monorepo
(googleapis/google-cloud-python, packages/bigquery-magics, currently
0.15.1), so check that out instead, using a sparse checkout to keep the
clone small. No other behaviour change: install order, the
graph_visualization import prepend, and the pytest targets are the same.
Verified locally by mirroring the job: 118 passed, 10 skipped with
google-cloud-bigquery 3.45.2.
The org-level "GitHub Actions Scan" (zizmor) check runs on any PR that
touches .github/workflows/*.yml and flagged this file:
* unpinned-uses (High, mandatory) x3: actions/checkout@v4 and
actions/setup-python@v5 are floating tags, not commit SHAs.
* excessive-permissions (Medium): no top-level permissions block.
* artipacked (Low): checkout steps persist the GITHUB_TOKEN in
.git/config.
Pin the actions to the commits those tags currently resolve to
(checkout v4.4.0, setup-python v5.6.0), add a read-only permissions
block, and set persist-credentials: false on both checkouts (nothing
after checkout needs git credentials). No behaviour change to the test
itself.
Verified with zizmor v1.25.2 and the same config the scan uses:
before: 3 high, 1 medium, 2 low; after: no findings.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The BQ Testing workflow fails on every new PR (first seen on #64, run 34348779661) with 2 failures in
python-bigquery-magics/tests/unit/bigquery/test_bigquery.py:test_bigquery_magic_with_bqstorage_from_argumentuser_agent == "ipython-… bigquery-magics/0.12.1""… bigquery-magics/0.12.1 legacy-gcb/3.45.2 pandas-gbq/0.0.0"test_bigquery_magic_query_variable_not_identifier"must be a fully-qualified ID" in stderr"Could not parse table_id. Expected a table ID such as 'project.dataset.table', …"Neither is related to this repo's code.
Root cause
The workflow checks out
googleapis/python-bigquery-magics, which was archived in March 2026 and is frozen atbigquery-magics 0.12.1. Itsgoogle-cloud-bigquery<4.0.0,>=3.13.0dependency is unpinned, so pip now resolves3.45.2, which changed the user-agent string and theTableReference.from_stringerror message. The archived tests will never be updated for this.The package now lives in the
google-cloud-pythonmonorepo underpackages/bigquery-magics(currently 0.15.1), where both tests have already been fixed (user_agent.startswith(...)and"table_id" in output).Fix
Check out the monorepo instead (sparse checkout of
packages/bigquery-magicsto keep the clone small) and update the paths via aBQMshell variable. Install order, thegraph_visualizationimport prepend, and the pytest targets are unchanged. The monoreposetup.pystill declaresspanner-graph-notebookonly as an optional extra, so the editable install of this repo is still what gets tested.Verification
Mirrored the job locally (sparse clone → venv →
pip install -e .→pip install -e ./$BQM→ prepend → pytest) withgoogle-cloud-bigquery 3.45.2/bigquery-magics 0.15.1:(vs.
2 failed, 114 passed, 10 skippedin the failing CI run.) This PR also exercises the new workflow itself via its own BQ Testing check.Follow-up
Once merged, #64 will pick this up automatically on its next push (or a close/reopen); a plain "Re-run jobs" won't, since re-runs reuse the original merge SHA.
Zizmor (GitHub Actions Scan) compliance
The org-level zizmor check scans any workflow file a PR touches and flagged pre-existing issues in this file. Second commit fixes them all (verified locally with zizmor v1.25.2 + the same config: before
3 high, 1 medium, 2 low→ afterno findings):unpinned-uses(High, mandatory): pinnedactions/checkout→11d5960a(v4.4.0) andactions/setup-python→a26af69b(v5.6.0), i.e. the commits the@v4/@v5tags resolve to today.excessive-permissions(Medium): added top-levelpermissions: contents: read.artipacked(Low):persist-credentials: falseon both checkouts (nothing downstream needs git credentials).frontend-tests.ymlandpublish-to-pypi.ymlhave the same unpinned-uses pattern and will trip the scan the next time they're edited; left for a separate PR to keep this one scoped.