custom-metrics-apiserver
custom-metrics-apiserver copied to clipboard
Synchronize test-adapter and Getting Started Guide
Currently, the Getting Started Guide includes pieces of code which, combined, give a sample adapter, different from the test-adapter.
That leads to two issues:
- code in the Getting Started Guide is not compiled or tested. The last fix in #108 showed lots of inconsistencies (e.g. different name for a same variable in the code) or outdated code (e.g. the adapter had not been updated for the Interfaces changes).
- there's 2 "test adapters" to maintain, and both are meant to serve as an example implementation (the "test-adapter" is also used for unit tests and is compiled during CI). These test adapters may diverge.
To tackle the first issue, we could enforce the Markdown from Getting Started Guide to be synced with Go code (e.g. kube-prometheus uses mdox to check that Jsonnet examples from its Markdown documentation is synced with Jsonnet files - cf here).
Ideally, we would have a single test implementation (test-adapter).
However, test-adapter is more complex than the implementation from the Getting Started Guide...
What do you think?
/assign @olivierlemasle /triage accepted
/kind documentation
Created PR #138 to try this mdox solution.
It "solves" issue 1 (compiling / testing code snippets in documentation), but not issue 2 (having 2 test adapters).
However, I wonder if it's really an issue. The current "test-adapter" may be better suited for tests (end to end tests to be created, unit tests), and this "sample-adapter" is an entry-level example.
This issue has not been updated in over 1 year, and should be re-triaged.
You can:
- Confirm that this issue is still relevant with
/triage accepted(org members only) - Close this issue with
/close
For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/
/remove-triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle rotten - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Reopen this issue with
/reopen - Mark this issue as fresh with
/remove-lifecycle rotten - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
In response to this:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied- After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied- After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closedYou can:
- Reopen this issue with
/reopen- Mark this issue as fresh with
/remove-lifecycle rotten- Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.