verify: The issue (#42) quotes the "log-to-a-file" section of the ops integrat

[github-actions]

The issue (#42) quotes the "log-to-a-file" section of the ops integration-testing docs, which recommends putting log_level = "INFO" in [tool.pytest.ini_options] so that "INFO logs [are] retained in the 'Captured log call' section when run interactively." The author believes log_level = "INFO" has no effect on Jubilant's output during an integration test.

I disagree with the author. My understanding of pytest's logging is that log_level and log_cli_level are independent controls: log_cli_level governs the live console output, while log_level governs the capture handler that feeds the "Captured log call" section (and the caplog fixture), with a default of WARNING. So even though every charm already sets log_cli_level = "INFO" (which is why Jubilant's INFO progress shows up live), without log_level = "INFO" the capture handler stays at WARNING and Jubilant's INFO records are filtered out of the captured section; adding log_level = "INFO" lowers that handler to INFO and retains them. In other words, log_level = "INFO" does affect the captured Jubilant output (just not the live output), so the doc's core claim is correct and the author's "no effect" belief is wrong — at least when log_cli_level is already INFO.

I tested this with a differential: I added the same integration test, test_jubilant_info_logs_captured, to both kepler and kosmos (their test_charm.py files were already identical, so the two versions are identical modulo the marker). The test runs juju.wait(jubilant.all_active) for real Jubilant activity, forces the jubilant logger to emit at INFO, emits an INFO probe record on Jubilant's logger, and asserts that caplog captured a jubilant-namespaced record at level >= INFO. The only difference between the charms is the config under test: I added log_level = "INFO" to kepler's pyproject.toml (so the capture handler is at INFO and the probe is retained — this test is expected to pass), and left kosmos at the default (capture handler at WARNING, so the INFO probe is filtered out — this test is marked @pytest.mark.xfail(strict=True) and is expected to fail).

What the CI result means: if CI is green, kepler's test passed (INFO retained with log_level = "INFO") and kosmos's test xfailed as expected (INFO filtered without it), which demonstrates that log_level = "INFO" genuinely changes whether Jubilant's INFO logs reach the captured-log section — so the doc's claim is validated and the author is refuted. If kosmos's xfail instead unexpectedly passes (xpassed under strict=True, turning CI red), that means Jubilant's INFO logs were captured even without log_level = "INFO" — i.e. log_level made no difference here (likely because log_cli_level = "INFO" already drove the capture level), which would mean the author is right and the doc's recommendation is redundant in this configuration. I aimed for green because I believe log_level independently governs the capture handler. run_tox passes (format, lint with pyright 0 errors, and unit) for both kepler and kosmos; the integration tests themselves only run in per-charm CI once the PR is marked ready.

[github-actions]

This PR is a draft. Inspect the changes, then mark it ready for review to run CI.

[github-actions]

This PR is a draft. Inspect the changes, then mark it ready for review to run CI.