• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

Unleash / unleash / 31502921600
87%
master: 91%

Build:
Build:
LAST BUILD BRANCH: main
DEFAULT BRANCH: master
Ran 11 Aug 2026 02:46PM UTC
Jobs 1
Files 1208
Run time 4min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

11 Aug 2026 02:40PM UTC coverage: 87.393% (-0.06%) from 87.457%
31502921600

push

github

web-flow
feat: securely store personal and service account tokens

## Summary

Extends secure storage to personal access tokens (PATs) and
service-account tokens behind the dedicated `secureAccountTokenStorage`
flag.

## Why this is safe to roll out

PAT and service-account secrets are shown only in the one-time creation
dialog. Their list APIs do not return the secret and their UI tables do
not provide a copy action. Secure storage therefore preserves the
established behaviour: the secret cannot be retrieved after creation.

## Storage and authentication

`personal_access_tokens` remains the backing table. The migration
permits exactly one credential shape per row:

- legacy: raw `secret`, retaining the existing storage behaviour. It
remains indexed for lookup, but is intentionally not made newly unique
so an instance with historic or manually altered duplicate data can
still migrate.
- secure: `selector` + `verifier`, with a unique selector; the raw
secret is never persisted.

Secure authentication looks up by selector in the store and verifies the
credential in `AccountService`; after successful authentication, only
the selector is added to the batched last-seen state.

## Deliberate difference from API token v2

This does not introduce a separate account-token-v2 store/service. API
tokens have a distinct lifecycle and management API, whereas PATs and
service-account tokens already share the account-token lifecycle,
ownership model, storage table, and authorization outcome.

The trade-off is mixed v1/v2 persistence at the account-token edge. A
separate service/table would make that split more explicit but would
duplicate the account-token domain and force merging two shapes further
into the system. We instead contain version-specific persistence and
verification at the boundary, then treat verified credentials as account
access.

---------

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

1994 of 2198 branches covered (90.72%)

26 of 49 new or added lines in 5 files covered. (53.06%)

4 existing lines in 4 files now uncovered.

15756 of 18029 relevant lines covered (87.39%)

825.69 hits per line

Uncovered Changes

Lines Coverage ∆ File
19
39.74
-11.13% src/lib/db/account-store.ts
4
79.31
5.4% src/lib/services/account-service.ts

Coverage Regressions

Lines Coverage ∆ File
1
39.74
-11.13% src/lib/db/account-store.ts
1
92.16
-1.96% src/lib/features/feature-toggle/configuration-revision-service.ts
1
85.59
3.39% src/lib/features/playground/feature-evaluator/constraint.ts
1
79.31
5.4% src/lib/services/account-service.ts
Jobs
ID Job ID Ran Files Coverage
1 31502921600.1 11 Aug 2026 02:46PM UTC 1208
87.39
GitHub Action Run
Source Files on build 31502921600
  • Tree
  • List 1208
  • Changed 9
  • Source Changed 7
  • Coverage Changed 9
Coverage ∆ File Lines Relevant Covered Missed Hits/Line Branch Hits Branch Misses
  • Back to Repo
  • Github Actions Build #31502921600
  • c0977aad on github
  • Prev Build on main (#31475870144)
  • Next Build on main (#31605729598)
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE TRIAL · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc