Support fetching tokens from an external command

[ammachado]

Summary

• Add token_command as a third token source alongside token / token_file, so plugins can pull secrets from password managers such as BitWarden (bw get password did-jira) or 1Password (op read op://Personal/Jira/token). The command is parsed with shlex (no shell) and its stripped stdout is used as the token; failures raise ConfigError. Results are memoized per process via functools.lru_cache so multiple config sections sharing a command only invoke the external tool once.
• Precedence when more than one of token, token_file, token_command is set in a section: token > token_file > token_command, matching the existing token vs. token_file precedence — lower-precedence keys are silently ignored, same as before.
• Updated the jira, confluence, github, and gitlab plugin docstrings to document token_command and the precedence rule. Other plugins automatically gain the feature through the shared did.base.get_token helper.

Test plan

• pytest tests/unit/test_base.py::TestGetToken — 13/13 passing (5 new tests for the command source, precedence, failure modes, and memoization)
• Full pytest tests/unit -n auto clean except for pre-existing failures unrelated to token handling (nitrate/psycopg2 build needs pg_config locally; one redmine live-data test)
• CI runs the full suite with .[all] installed
• Manual smoke: configure a plugin with token_command = printf %s ... and confirm the report runs

🤖 Generated with Claude Code

[ammachado]

Note on integration test count updates (tests/github/issues.sh, tests/github/pulls.sh)

@psss, while investigating CI failures in Testing Farm, I found that two items are no longer being returned by the GitHub Search API for the 2022 date range:

• teemtee/fmf#149 — missing from all "issues created/closed" queries
• teemtee/try#002 — missing from all "pull requests created" queries

Both items are still visible by direct URL, so they have not been deleted. The root cause is GitHub Search API inconsistency: the index is eventually consistent and does not guarantee that all matching items are returned, especially for older closed issues/PRs. I confirmed the failure also reproduces on main, so this is not a regression introduced by this PR. The same behavior is also observed in PRs #468 and #470.

As a short-term fix I updated the expected counts and dropped the specific rlAssertGrep assertions for the two missing items.

I'd like your advice on how to handle this long-term. A few options I can think of:

1. Keep exact counts (current approach) — simple to read, but requires manual updates whenever the Search index drifts. Will happen again.
2. Drop count assertions entirely — only assert that specific known items are present/absent. More resilient to index drift, but loses the sanity check that ensures we're not silently fetching zero results.
3. Use a lower-bound check — e.g. assert the count is >= N rather than == N. Beakerlib doesn't support this natively but it could be done with a small shell snippet.
4. Pin the test to a narrower, stable date range where the result set is small enough that index drift is unlikely to drop items.

What is the preferred approach for this project?

[psss]

@ammachado, thanks for looking into the test issues. Yes, it really seems that some of the expected issues are not included in the search results anymore. Interestingly, for pull requests your changes seem not needed anymore. Something weird is happening on the GitHub side. Here's a slightly modified version of your adjustments:

• Modify github test data #473

[psss]

Thanks much for implementing this! Looks good, just two minor comments. Also the following statement from the pull request description is not valid, right?

• Breaking change: setting more than one of token, token_file, token_command in a section is now a hard ConfigError. Previously the lower-precedence keys were silently ignored.

[psss]

Thanks for the changes. Added one more missing pre-commit dependency in 4cd37b4. Should be good to go.

[lukaszachy]

LGTM, finally a safer way to store tokens

[kwk]

I do like the idea of using Bitwarden. But I'm sorry but I have a few questions and annotations.

[ammachado]

@kwk, all fourteen threads from your review are answered, and the branch is rebased on current main. Could you take another look when you have a moment?

Changed in 179036d:

• token_command added to the gitlab and jira config examples, next to the token / token_file entries that were already listed
• Clarified "without a shell": the command inherits did's environment, so BW_SESSION and friends are visible. Only shell expansion is missing (no pipes, redirects, $VAR, globs). Documented in both the jira plugin docstring and _run_token_command
• The command line is now included in all three error paths, not just the timeout one
• Documented why caching the token for the process lifetime does not widen exposure of the secret
• Reworded the "memoized" comment that read as a typo

Answered without a code change, reasoning in each thread:

• Optional[str] stays, since setup.py still declares Python 3.9 and PEP 604 is 3.10+. from __future__ import annotations would let us switch, but repo-wide rather than in this PR
• did/stats.py: the old line printed a Future repr, and a failing token_command surfaces through exactly that line
• did/utils.py colour reset and the three test assertions that follow from it: I overstated this as a bug fix in the commit message, it is a cleanup. Corrected in the thread
• .pre-commit-config.yaml: pylint was hitting import-error, mirroring the list the mypy hook already carries

I offered in several threads to split the colour-reset and pre-commit changes into separate PRs if you would still prefer this one narrower. Happy to do that, just say which.

One note on CI: the four Fedora testing-farm jobs are red, but not because of this branch. pagure.io's REST API is currently returning 404 for every path, including https://pagure.io/api/0/version, while the web UI is up. That fails the five tests/unit/plugins/test_pagure.py tests. The same five fail on unmodified main, and this PR touches no pagure code. The CentOS Stream jobs pass because they do not run the unit plan.

[kwk]

Okay, let me make one thing clear, I like the feature. But I also like Big Buts (the song is cool as well but written differently).

Can we please get a policy for AI contributions? I simply do not buy that my last review was answered by a human. And I refuse to work this way.

I'm getting really angry about such comments. Not because they are incorrect or inaccurate but because I feel like someone is operating a machine instead of thinking for him or herself. This is disrespectful.

@psss please look at the responses and tell me this was written by a person.

[ammachado]

@kwk I use Claude Code to assist me, but I review all the work it does. This PR is not on autopilot. I'll move the color reset and log improvements to a different PR.

[ammachado]

Two new PR open: #481 (missing runtime dependencies for macOS) and #482 (log improvements)