cli/logs: persist dot color assignments across runs

[amirHdev]

Closes #683

Summary

Persist kubetail logs dot color assignments so containers keep the same color across CLI invocations.

Changes

• Added a persistent dot color state manager:
  • file-backed JSON store at ~/.kubetail/state/log-dot-colors.v1.json
  • schema versioning (schemaVersion) for upgrade handling
  • lock-based write coordination for concurrent CLI processes
  • atomic state writes
• Wired persistent color assignment into logs rendering flow.
• Kept safe fallback behavior: if persistence fails, dot color still renders via hash-based assignment.
• Added stale entry cleanup with TTL .
• Added tests for:
  • persistence across instantiations
  • schema mismatch/reset handling
  • stale entry cleanup

Validation

• cd modules/cli && go test ./cmd/...

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7b99254c99

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[amorey]

Thanks for your PR! Let me dig into this and do a proper review. In the mean time can you squash the commits and sign-off on the new commit (commit -s) so that the DCO check passes?

[amirHdev]

Thanks for your PR! Let me dig into this and do a proper review. In the mean time can you squash the commits and sign-off on the new commit (commit -s) so that the DCO check passes?

Implemented, thanks for the review.

[amorey]

@amirHdev Thanks again for the PR and apologies for the delay. There are definitely some useful things in this PR but I think we should hold off on implementing the feature until we get more feedback from users. The current hashing solution seems to be "good enough" so I'm hesitant to make big changes until users ask for it. However, this PR is useful for the planning stage so let's keep it open to help us later.

Here's another issue you might find interesting to work on: #970.

Currently, users are required to modify columns individually in the CLI output (e.g. --hide-ts, --with-region, --with-zone) which can get unwieldy. Instead I want to consolidate the column manipulation into these flags:

--columns
--add-columns
--remove-columns

After implementing that we should also make it configurable via the local config file. If you're interested in working on this let me know!

[amirHdev]

@amorey
Thanks for the thoughtful review, and no worries on timing.

That makes sense to me. I agree we should keep this PR open for planning/reference and hold off on merging until we get stronger user demand.

I’m happy to take on #970 next. I can work on consolidating column controls into:

• --columns
• --add-columns
• --remove-columns

and wire the same behavior into local config defaults as well.

If that sounds good, I’ll start with a proposal for column names/precedence (including migration behavior from existing flags) and then open a PR.

[amorey]

Sounds great! Starting with a proposal sounds like a good place to start. I’m happy to answer any questions you have technical or otherwise. You can DM me on discord if you want to chat too.

[amirHdev]

Sounds great! Starting with a proposal sounds like a good place to start. I’m happy to answer any questions you have technical or otherwise. You can DM me on discord if you want to chat too.

how can i connect with you in the Discord?

[amorey]

Just join our Discord and DM me there (same username as GitHub): https://discord.gg/CmsmWAVkvX