| Age | Commit message (Collapse) | Author |
|---|
|
Using npx does not guarantee works on system installed nodejs.
|
|
The fieldalignment and shadow is linter from golang.org/x/tools.
This linters actually have an API that can be combined into a program,
which provided by package "pakakeh.go/lib/goanalysis".
|
|
|
|
The flag "dev" is boolean that when set will run service in development
mode, watching the adoc and ts files.
The flag "http" is string that set the HTTP listen address.
|
|
|
|
This is so we can build again if its failed, after lint and test has
passed.
|
|
The task "init" include initializing git submodule, installing third
party tools for linters, and installing node packages.
|
|
The original idea of "trunks" is because the core library that we
use for load testing is named "vegeta" (from Dragon Ball) [1][2], and
Vegeta has a son named Trunks.
In English, trunks also have multiple meanings.
In order to have a unique name, we rename the project to "gorankusu",
which is a combination of "go" (the main programming language
that built the application) and "torankusu" the Hepburn of "Trunks".
[1]: https://github.com/tsenart/vegeta/
[2]: https://en.wikipedia.org/wiki/Vegeta
Implements: https://todo.sr.ht/~shulhan/gorankusu/2
|
|
|
|
Previously, we use golangci-lint as linter.
This linter does not provides any useful recommendation lately and the
development is quite a mess, sometimes its break when using Go tip.
In this changes we replace it with revive, fieldalignment, and shadow;
and fix all of their recommendations.
|
|
|
|
Some linter, govet, warns about possible copied Mutex on HttpRequest.
To fix this we implement method clone and Stringer on HttpRequest.
|
|
See https://kilabit.info/journal/2022/gpl for more information.
|
|
In case user set CGO_ENABLED=0, the task for "all" will fail.
This commit fix this by setting CGO_ENABLED to 1 when running test
with -race option.
|
|
The internal/cmd/trunks-example is not run and provide an example only
now, its include the workers to build, recompile, re-embeded files.
|
|
Previously, we have a workers to recompile TypeScript and regenerate
HTML files from adoc inside the Trunks type. The workers will run
if the environment variable TRUNKS_DEV set to non-zero.
This changes move those workers to the internal/cmd/trunks-example,
because those workers are related for development only not for running
Trunks server.
|
|
The "cmd" directory on module should be reserved for installable
program that can be executed outside of this repository.
The trunks-example is development server should be run on root of this
repository only, not installable to $GOBIN.
|
|
Changes,
* share: fix the HTTP caching using ETag on the server
* share: rename the terminology to generate Go source code to "embed"
* ciigo: check markup modification time before converting to HTML
|
|
Previously to developer and test trunks on local we need to run "tsc -w"
on directory _www to watch and recompile any changes to TypeScript files,
and run "go run ./cmd/trunks-example" to view the Trunks web interface.
Since we will have internal documentation inside _www/docs, we need
to run another ciigo server that watch any changes to .adoc files
and convert it to HTML.
Three separate commands for development.
This changes refactoring the development process by running two
goroutines when TRUNKS_DEV environment variable is set to non-empty.
One goroutine watch any changes to TypeScript, HTML, and
tsconfig files inside the _www, and when there is an update it will
execute "tsc -p" to recompile and "go run ./internal/generate-memfs" to
embed them into Go source.
Another goroutine watch any changes to .adoc files inside "_www/docs"
directory and convert them into HTML files.
This goroutine will running in the background while the HTTP server is
running too.
|
|
The "tsc" task run the tsc program using the tsconfig.json inside
the directory _www, which will recompile all TypeScript before generating
the embeded file.
|
|
Previously, the web user interface is written in pure, single JavaScript
file. The LOC is short but its become hard to maintenance, especially
when there is a change in HTML layout or on the response format.
This changes rewrite the interface to use TypeScript in order to easily
maintenance. The generated JavaScript is loaded using module [1].
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules
|
|
The content of _www directory is required to run the trunks as library.
|
|
The trunks directory on command is actually the main program for
example package.
|
|
* Increase the DEBUG value to 3 to match with latest libhttp fix
debug output of client request
* _www: fix rendering HTTP headers, missing "target" parameter
* Remove unused "IsRunning" from AttackResult
* example: add an example endpoint for POST with x-www-form-urlencoded
* Remove parameter Target on HttpRunHandler. The Target value can be
retrieved from RunRequest.Target.
* Target: change the field Vars type from map[string]string to KeyValue
* Trunks: merge Target and HttpRequest from request to original Target
and HttpTarget respectively before calling Run
* Prefix the result file name with Target.ID
* Move the package documentation to doc.go
|
|
Trunks is a library and HTTP service that provide web user interface
to test HTTP service, similar to Postman, and for load testing.
For the load testing we use vegeta [1] as the backend.
[1] https://github.com/tsenart/vegeta
|
