getapid / apid Goto Github PK

Create a template for documentation pages that has:

• Same header and footer as website
• Table of contents
• Heading for the doc section
• Doc content

Have a typical startup / cli landing page with:

• Hero with some lame call to action / slogan
• List of features
• Download call to actions
• Placeholder subscribe to mailing list

Define step.Service (change the name!) interface:
data passed step.Step
data returned step.ResultsBundle (name to be defined)

Have a config loader struct that has a default yaml file location, loads that file and unmarshalls it into an empty struct. Struct should take a file path that will be used if specified (instead of the default config file path)

Add simple function calling functionality in the templates engine.

Extend the console writer to write transaction data for:
Write list of transactions and for each transaction add the steps with a OK / ERROR state (and list of errors if applicable)

maybe add color

Remove step interpolation logic. Create transaction.Service (name to be changed) that has step.Service and MultiWriter as dependencies. Should loop over all transactions and forward results to the MultiWriter as they become available.

Use from scratch as a base image in a multistage Dockerfile. Default entrypoint should be the CLI.

Add a step in the pipeline to build and push the image to docker hub

Add docs about pretty much everything

Make a call to a login endpoint and export the auth token. Use the token in the next request to make an authenticated call to a "secure" endpoint.

Remove Header and Footer functions, header should be automatically applied either on init, or on first body call.

Body function should be renamed to something like WriteTransaction (your choice)

Add flags to root config for checking SSL expiry time and alerting

Write a blog post on how to test an API and in the e2e section promote apid

Create a result writer interface that will ingest data from the transaction results. One implementation is needed - console writer - that ingests data when available and publishes it to the console.

Data will be sent once for each transaction (once it finishes execution)

When making SSL requests add the functionality to ignore SSL issues.

Also add go generate as part of Makefile test step

Currently the exit code is always 0

Refactor the existing interpolator and Jason packages in a template package.

Add -v flag to the CLI that handles the verbosity level. Optional -vv or -vvv flags to add more information.

Add logs throughout the code.

Create a step.Executor struct that depends on a http.TimedClient and executes a step.PreparedStep. It should return the http.(Timed)Response object

Set up basic outline of a cobra command and basic parsing of config file path with viper

Create an config validator struct that takes a config script and validates it.

Add a way to validate the timing of the request is less than a specified value. So for example, I want the test to fail when the server processing time is more than 500ms, maybe with some margin of error.

This would include changes to the config/suite structure and to the result validator.

Changes to the config are up for discussion, so any suggestions are welcome :)

variables.Variables should hold all the data to be used in templates. It should have namespaces (vars and env) and when passed a map[string]interface{} for the particular namespace should perform a merge, rather than override the contents of the namespace.

Make a http and https calls to different API endpoints.
Add endpoints plus e2e test.
Make sure it handles http and https errors properly.

Create a "wrapper" around the standard HttpClient that times network latencies on different levels. The client should return the timings and the response of each request.

go/common/template/template.go only inserts data if it's a string, need to extend that with numbers int / float / etc

Self signed or expired SSL certs should be ignored if SSL error ignore flag is set to true.
Add endpoints and e2e test.

Add google analytics to the site so we can monitor traffic and engagement.

Create a new github action that runs for pull requests that tests and builds the cli. This is only to verify everything is in order and buildable.

Hook up mailchimp (or other) for mailing list signups.

Install logging framework go.uber.org/zap

We need a way of getting questions or suggestions from users. At least an email should be ok. Or maybe a discord room?

org name - apid or something like this

Create a step interpolator that takes a step.Step and and variables.Variables. It should interpolate all fields that are expected to have template variables (look at transaction.StepInterpolator)

Change the name of the response field in a step to expect

Add a version field on the config file to support future expansion of the templating language and new features.

Same as docs template, but without a table of contents.

We should be able to load config files from a directory. If the -c value is a directory, then recursively load all .yaml or .yml files and merge them together in a Config, or return a list of the Configs (and modify the cli command to run that list).

Two things:

• the CLI doesn't have a version command
• we aren't using the version file in the root of the repo

Would be nice if the patch in the version file was incremented each time we release and then this was injected in the compiled binary somehow. Since we're in something like alpha now, this should suffice as a version for now.

Instead of supplying a config.yaml file, the user can supply a directory and the tool should look (recursively) for yaml files and try to load them.

Recreate the config struct from the test yaml file in the repository.

Create a dummy API in go with:

• a healthcheck endpoint that returns body "OK" and status code 200
• an echo endpoint which returns whatever you passed it

Add the API to be executed on pull requests and releases (as e2e test of sorts)

Now the downloaded binary is called cli-latest-{os}-{arch}, it should be called apid

Also maybe make it a tgz and zip files depending on the os?

• currently the timestamp in a zap entry is represented as a float; make it human readable or at least a unix timestamp as an int
• we default to logging at -1, which should be made a flag defaulting to warning or error (IMO by default we shouldn't be showing zap log entries)
• revisit places where we log with log.L.Error and change them to either warn or directly use fmt.Println

Create a MultiWriter struct, which implements the Writer interface. It will have a list of writer it forwards results to.

Create a step.Validator package that takes a step.PreparedStep and a http.(Timed)Response and checks that the expect block is indeed what is in the response. It should return a bool and/or a list of errors.

title says it all