enriqueesanchz/test_auth
Watch
1
0
Fork
You've already forked test_auth
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
No description
2 commits 1 branch 0 tags 7.7 KiB
Find a file
Exact
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Copilot 9b543e898b
Some checks failed
test-keyring-theory / guard-step-nonempty-secret-passes (push) Successful in 3s
Details
test-keyring-theory / guard-step-empty-secret-fails-early (push) Failing after 4s
Details
test-keyring-theory / no-auth-should-fail-with-nokeyringerror (push) Successful in 1m27s
Details
test-keyring-theory / with-bogus-auth-should-not-hit-keyring (push) Successful in 1m31s
Details
Use upload-resource (not whoami) to reproduce legacy Store NoKeyringError 
whoami uses the newer StoreService which gracefully falls back on
NoKeyringError. upload-resource uses the legacy Store class, which
re-raises it as a hard failure - that's the actual code path we need
to reproduce.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-09-25 16:19:49 +02:00
.forgejo/workflows Use upload-resource (not whoami) to reproduce legacy Store NoKeyringError 2026-09-25 16:19:49 +02:00
README.md Add workflow to verify CHARMCRAFT_TOKEN/keyring theory 2026-09-25 16:14:30 +02:00

README.md

test_auth

Scratch repo to validate the root cause of the charmcraft upload-resource failure ("No keyring found to store or retrieve credentials from.") seen in lp-forgejo-actions' publish-charm.yaml reusable workflow.

Theory

charmcraft's legacy Store client (used by upload-resource) reads credentials from the CHARMCRAFT_AUTH env var. If that variable is unset or empty, os.getenv() returns a falsy value, so charmcraft falls back to the system keyring instead. In a bare ubuntu:24.04 container (no dbus/secret-service), that keyring lookup fails and charmcraft hard-fails with NoKeyringError — exactly the observed error. This happens when the caller of the reusable workflow doesn't define a non-empty CHARMCRAFT_TOKEN secret (or doesn't pass secrets with secrets: inherit).

Workflow: .forgejo/workflows/test-keyring-theory.yaml

Runs 4 jobs on push/dispatch:

  1. no-auth-should-fail-with-nokeyringerror — runs charmcraft whoami with CHARMCRAFT_AUTH="". Expected: fails with NoKeyringError (confirms the theory).
  2. with-bogus-auth-should-not-hit-keyring — same command with CHARMCRAFT_AUTH set to a non-empty (but invalid) value. Expected: fails differently (e.g. auth/network error), never hits the keyring path.
  3. guard-step-empty-secret-fails-early — copy of the new guard step added to publish-charm.yaml; intentionally fails when the secret is empty. A failed run of this job is the expected/desired result.
  4. guard-step-nonempty-secret-passes — same guard step with a non-empty value; expected to succeed.

Conclusion

If jobs 1, 2, and 4 succeed (and job 3 fails as intended), it confirms: the original failure was caused by a missing/empty CHARMCRAFT_TOKEN secret on the caller side, not a charmcraft/container bug, and the new guard step in publish-charm.yaml correctly fails fast with an actionable error message instead of the more confusing charmcraft/keyring error.