Skip doc examples requiring secrets on fork PRs

[burnash]

When a PR comes from a fork, GitHub Actions doesn't expose repository secrets. This causes the docs examples tests to fail because many examples require external credentials (Postgres, BigQuery, Slack webhooks, etc.).

This PR adds an EXAMPLES_REQUIRING_SECRETS list to prepare_examples_tests.py that skips these examples when IS_FORK=true.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	docs	8b884fa	Commit Preview URL Branch Preview URL	Dec 05 2025, 02:51 PM

[djudjuu]

we have a helper:

dlt/tests/utils.py

Line 551 in d9e15a7

def is_running_in_github_fork() -> bool:

def is_running_in_github_fork() -> bool:
    """Check if executed by GitHub Actions, in a repo fork."""
    is_github_actions = is_running_in_github_ci()
    is_fork = os.environ.get("IS_FORK") == "true"  # custom var set by us in the workflow's YAML
    return is_github_actions and is_fork
    ```

[burnash]

Good point! However, the prepare_examples_tests.py script is in docs/docs_tools/examples/ and isn't a pytest test file, rather a standalone script that generates test files. Importing from tests/utils would create an awkward dependency from the docs tooling on the test utilities module. Additionally, the existing helper is_running_in_github_fork() does an extra check for GITHUB_ACTIONS == "true" via is_running_in_github_ci, but here we only need to check IS_FORK since this script only runs in CI anyway (and having IS_FORK=true already implies ci context)

If we want to keep things consistent, we could either:

1. Keep it as-is (simple inline check, no dependency)
2. Extract a shared utility for fork detection that both modules can use

I'd lean toward keeping it simple here, but happy to refactor if you prefer.

[djudjuu]

ah true... lets definitely not import that. option 2 is fine!

[djudjuu]

learning question: why this example?

[burnash]

custom_naming example uses dlt.destinations.postgres() which requires Postgres credentials

dlt/docs/examples/custom_naming/custom_naming.py

Line 36 in 289e00d

dest_ = dlt.destinations.postgres(naming_convention="sql_cs_latin2")

[djudjuu]

makes sense...so its just a bit inconsistent that this example doesnt include a example.secrets.toml

[djudjuu]

question:partial_loading also uses aws creds so should be in there?

[burnash]

partial_loading example, it uses local filesystem storage, not aws/s3 creds:

dlt/docs/examples/partial_loading/partial_loading.py

Line 143 in 289e00d

dest_ = dlt.destinations.filesystem("_storage")

[djudjuu]

ah right, and in filesystem the bucket_url (assigned above) is used to determine the kind of credential needed (and local filesystem doesnt require any so nothing ever gets resolved)

[djudjuu]

its an improvement. i guess we always pay special attention when merging outside stuff.
I assume tests also run on the merged devel branch so we should see failing examples there as well...or on the next pr that comes after and doesnt touch the code (not ideal, but better than now)

also: left two questions and a nitpick

[burnash]

Thanks for the review @djudjuu, afaik the tests won't rerun on merge to devel.

[djudjuu]

Thanks for the review @djudjuu, afaik the tests won't rerun on merge to devel.
ah true...i clicked on the action and its just the deploy job