feat: [CHAOS-12655]: Add RT (Resilience Testing) CLI support for loadtesting capabilities - #131
Open
uditgaurav wants to merge 1 commit into
Open
feat: [CHAOS-12655]: Add RT (Resilience Testing) CLI support for loadtesting capabilities#131uditgaurav wants to merge 1 commit into
uditgaurav wants to merge 1 commit into
Conversation
… testing capabilities Signed-off-by: Udit Gaurav <udit.gaurav@harness.io>
|
|
Collaborator
|
Thanks for raising the PR @uditgaurav . Team will be reviewing this soon. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add RT (Resilience Testing) CLI support for load testing
What this is
Adds
rt— the Resilience Testing module — to the Harness CLI. Load testing had no CLIsurface at all before this; you could only drive it from the console.
41 commands over 41 distinct LTM REST routes, covering the full lifecycle: define a load
test, attach a script, run it, watch it, and read the results.
RT is the module.
loadtestis the noun you type — load testing is the first feature areaunder RT, and chaos is expected to land alongside it, so nothing in the module assumes load
tests are all it holds.
Scope
Deliberately minimal footprint outside the module:
pkg/spec/rt.spec.yamlmodules/rt/cmd/harness/main-harness.goNothing else is touched. No framework changes, no shared-file edits.
Command surface
All 41 commands
loadtest (11) —
list·get·create·create:from_json·create:from_template·update·update:json_spec·delete·list:variables·execute:sync·executeloadtest_run (10) —
list·get·update·execute:stop·execute:rerun·get:summary·list:metrics·list:graph·list:requests·list:endpointsloadtest_script (4) —
get·update·list:revisions·get:revisionloadtest_template (11) —
list·get·create·update·delete·list:revisions·create:revision·get:revision·delete:revision·list:variables·get:yamlcomposite_loadtest (2) —
list·createloadtest_usage (3) —
list·get·get:reportharness get module rtprints the domain model and the full command list — no credentialsneeded, and it is probably the fastest way to review the surface.
What is in Go, and why
39 of the 41 commands are declarative
endpoint:blocks in the spec.modules/rt/holds onlywhat YAML cannot express:
start_runvalues[{name,value}]array rather than a flat objectencode_script-fhandling sends the file as-iscomposite_bodyidentifier(notidentity) and rejects hyphens server-side with an HTTP 500 quoting a pipeline rule that names no argument — checked client-side firstwatch(--follow)--follow --format json > run.jsonstill yields one documentreruntemplate:yamlapplication/x-yaml, which the shared client's unconditionaljson.Unmarshalcannot decodeusage:report--format/--columnsworkloadtest_filters--tagis repeatable, and a list flag inquery_paramsships as the literal"[]"when unset — the API reads that as a tag nothing carries and returns an empty page, silentlyTesting
modules/rtcoverage: 96.0%, via a fake-server harness (apitest_test.go) that spins anhttptestserver against a real registry, soModuleInitwiring is exercised rather thanmocked.
Live-verified against QA (account
DSzI0EehTMqGVdfsfG3a5g): the read paths on this exactbuild —
list loadtest,list loadtest_run,get loadtest_run:summary,get loadtest_usage.Write paths (
create/update/delete/execute) are covered by unit tests and wereverified live during earlier QA rounds against the pre-rename shape.
gofmt,go vet, fullgo test ./...andHARNESS_CHECKSPECS=1all clean.Notes for reviewers
iacm→workspaceandcode→repository.gitopsis the counter-example if you would rather seert_loadtest; happy toswitch, it is a mechanical change.
/load-tests,loadTestIdentity)while everything user-facing is
loadtest. That asymmetry is intentional, not an oversight.