Skip to content

docs: centralize CONTRIBUTING.rst pointers - #17642

Draft
chalmerlowe wants to merge 12 commits into
mainfrom
feat/centralize-contributing
Draft

docs: centralize CONTRIBUTING.rst pointers#17642
chalmerlowe wants to merge 12 commits into
mainfrom
feat/centralize-contributing

Conversation

@chalmerlowe

@chalmerlowe chalmerlowe commented Jul 7, 2026

Copy link
Copy Markdown
Contributor

Problem

  1. Each package has a CONTRIBUTING.rst file and each file contained references to supported Python runtimes and specific dependency versions, etc.
  2. The references to supported runtimes and needed dependencies needed to be updated every time we changed the install environment, which was unnecessary toil.

Solution

  1. Centralized package-level CONTRIBUTING.rst files to point to the repository root for handwritten libraries.
  2. Removed references to which Python runtime versions apply to this package and points users to the noxfile.py, setup.py, and pyproject.toml as sources of truth for runtimes and other dependencies.

Out of Scope/Future work

  1. Update GAPIC templates to point at the central CONTRIBUTING.rst file.

Blocked by #18037

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request standardizes the 'CONTRIBUTING.rst' files across the monorepo by centralizing the guidelines and pointing to a root-level document. A minor issue was identified in the main 'CONTRIBUTING.rst' file where a link target was incorrectly defined, which would cause documentation build errors. The reviewer provided a correction for this link target.

Comment thread CONTRIBUTING.rst Outdated
@chalmerlowe chalmerlowe added the kokoro:force-run Add this label to force Kokoro to re-run the tests. label Jul 16, 2026
Comment thread CONTRIBUTING.rst Outdated
@yoshi-kokoro yoshi-kokoro removed the kokoro:force-run Add this label to force Kokoro to re-run the tests. label Jul 21, 2026
chalmerlowe added a commit that referenced this pull request Jul 23, 2026
## The Problem
Two unit tests in `google-cloud-bigquery`
(`test_result_w_retry_wo_state` and `test_result_w_custom_retry`) were
failing intermittently with a `TimeoutError` or `RetryError`. This
flakiness occurs because the tests use a very short inner retry deadline
of 0.1 seconds. Under heavy load (such as during parallel testing or on
constrained continuous integration runners), this deadline can be
exceeded, causing the test to fail confusingly.

## The Solution
Increased the `deadline` parameter for the custom retry objects in both
tests from 0.1 seconds to 1.0 seconds. This provides enough buffer for
the test assertions to complete without timing out, aligning with other
similar tests in the suite.

## Notes to Reviewers
- This change only affects unit tests and does not alter production
code.
- This issue is blocking:
  - #17642
  - #17608

Here is a snippet of the failure:
```python
    def test_result_w_retry_wo_state(global_time_lock):
        from google.cloud.bigquery.retry import DEFAULT_GET_JOB_TIMEOUT
    
        begun_job_resource = helpers._make_job_resource(
            job_id=JOB_ID, project_id=PROJECT, location="EU", started=True
        )
        done_job_resource = helpers._make_job_resource(
            job_id=JOB_ID,
            project_id=PROJECT,
            location="EU",
            started=True,
            ended=True,
        )
        conn = helpers.make_connection(
            exceptions.NotFound("not normally retriable"),
            begun_job_resource,
            exceptions.NotFound("not normally retriable"),
            done_job_resource,
        )
        client = helpers._make_client(project=PROJECT, connection=conn)
        job = google.cloud.bigquery.job._AsyncJob(
            google.cloud.bigquery.job._JobReference(JOB_ID, PROJECT, "EU"), client
        )
        custom_predicate = mock.Mock()
        custom_predicate.return_value = True
        custom_retry = google.api_core.retry.Retry(
            predicate=custom_predicate,
            initial=0.001,
            maximum=0.001,
            deadline=0.1,
        )
>       assert job.result(retry=custom_retry) is job
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

tests/unit/job/test_async_job_retry.py:115: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
google/cloud/bigquery/job/base.py:1047: in result
    return super(_AsyncJob, self).result(timeout=timeout, retry=retry)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.nox/unit-3-12-test_type-unit/lib/python3.12/site-packages/google/api_core/future/polling.py:256: in result
    self._blocking_poll(timeout=timeout, retry=retry, polling=polling)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = _AsyncJob<project=test-project, location=EU, id=test-job-id>
timeout = None
retry = <google.api_core.retry.retry_unary.Retry object at 0x7ff2beda32c0>
polling = <google.api_core.retry.retry_unary.Retry object at 0x7ff2beda01d0>

    def _blocking_poll(self, timeout=_DEFAULT_VALUE, retry=None, polling=None):
        """Poll and wait for the Future to be resolved."""
    
        if self._result_set:
            return
    
        polling = polling or self._polling
        if timeout is not PollingFuture._DEFAULT_VALUE:
            polling = polling.with_timeout(timeout)
    
        try:
            polling(self._done_or_raise)(retry=retry)
        except exceptions.RetryError:
>           raise concurrent.futures.TimeoutError(
                f"Operation did not complete within the designated timeout of "
                f"{polling.timeout} seconds."
            )
E           TimeoutError: Operation did not complete within the designated timeout of None seconds.
```
Comment thread CONTRIBUTING.rst Outdated
Comment thread CONTRIBUTING.rst Outdated
Comment thread CONTRIBUTING.rst Outdated
@chalmerlowe

Copy link
Copy Markdown
Contributor Author

Blocked by #18037

parthea pushed a commit that referenced this pull request Aug 10, 2026
…17555)

### Problem
The OS X python wheel build script (`build_python_wheel.sh`) checks if a
Python version is installed in `pyenv` before building:

```bash
if [ -z "$(pyenv versions --bare | grep $version)" ]
```

When $version is 3.14, this expands to grep 3.14. Because the dot (.) is
not escaped, it is treated as a wildcard and will also match the
substring 3.13.14 (which contains 3.<any char>14 at the end). This
results in a false positive, causing the script to skip compiling Python
3.14. The script then fails when executing pyenv shell 3.14 with a
"version not installed" error.

### Solution
Escape the version dots in bash: `${version//./\.}.`
Anchor the grep match with line start (`^`) and word boundaries (`\b`)
to ensure it only matches the exact version line (e.g. `^3\.14\b`
instead of matching `3.13.14`).
Applied this fix to both `build_python_wheel.sh` and
`publish_python_wheel.sh`.

Blocks: #17642
parthea pushed a commit that referenced this pull request Aug 10, 2026
#### Problem
The `test_init_default_client_info` tests in `google-cloud-pubsub` (for
both Publisher and Subscriber) were **brittle** because they peeked into
the private internal attributes of `_GapicCallable` (from
`google-api-core`) to verify metadata.
Recent refactoring in `google-api-core` renamed/removed the `_metadata`
attribute, causing these tests to fail with `AttributeError:
'_GapicCallable' object has no attribute '_metadata'`.

#### Solution
Refactored `test_init_default_client_info` in `test_publisher_client.py`
and `test_subscriber_client.py` to use **mocking** instead of peeking
into internal state.

* The tests now use `unittest.mock.patch` to intercept calls to
`google.api_core.gapic_v1.method.wrap_method`.
* We verify that `wrap_method` is called with the expected `client_info`
object.
* We assert that the `client_info` contains the correct library version
string (e.g., `gccl/x.y.z`).

#### Why this is important
* **Robustness:** Tests are no longer dependent on internal
implementation details or private attributes of downstream libraries
(`google-api-core`).
* **Future-Proof:** Prevents test failures when internal state is
refactored, as long as the public-facing helper signature
(`wrap_method`) remains stable.
* **Consistency:** Aligns with the testing patterns already adopted by
other modern clients in this monorepo (e.g.,
`google-cloud-bigquery-storage`).


Blocks: #17642
@chalmerlowe
chalmerlowe force-pushed the feat/centralize-contributing branch from db08071 to 98373ad Compare August 10, 2026 15:35
@chalmerlowe
chalmerlowe force-pushed the feat/centralize-contributing branch from c659147 to 2d7ac0e Compare August 11, 2026 08:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants