tests: initial commit of the manual tests

[leonardo-albertovich]

Please do not merge this PR.

In order to use these tests you need to set your working directory to tests/leonardo and then execute the outer shell scripts one by one.

Each one of these will start a data source (fluent-bit, vector, opentelemetry collector, shell scripts, etc.) and a data sinc which is the fluent-bit binary we are trying to test.

The path to the binary (as well as other settings) can be passed through environment variables, otherwise the shell script will look for fluent-bit inside the bin directory and its parents bin directory (in case this is executed inside the build directory of a fluent-bit working tree).

The scripts will automatically elevate privileges when required and also perform a crude teardown after the test is terminated.

These are manual tests, there is no automatic compliance detection at all so far and that's not the intention either.

[patrick-stephens]

Let's adapt these over to BATS and then can go straight in as integration tests: https://bats-core.readthedocs.io/en/stable/

We likely need to support a configurable version or location, I think the current assumption is native binaries but containers may be better - or we could make this a Linux matrix test of various packages: install the package first then run it through tests.

[patrick-stephens]

@leonardo-albertovich anything specific you still need on top of this? Cluster creation, etc.?

[leonardo-albertovich]

Just the test cases for filter_kubernetes, filter_aws and filter_ecs.

[patrick-stephens]

Just the test cases for filter_kubernetes, filter_aws and filter_ecs.

So filter_kubernetes should drop straight into the current integration tests as these all run on KIND, EKS and GKE already.
We can add some simple basic checks that it provides kubernetes metadata in the output.
use_kubelet was the other area I wanted to test as seems problematic with TLS but I think not for an initial one.
Any other specific K8S filter checks you think @leonardo-albertovich ?

filter_ecs - what does this filter do? It looks to be this one: https://docs.fluentbit.io/manual/pipeline/filters/ecs-metadata
Too many ECS acronyms! We will need to provision an ECS cluster for this in Terraform then run the tests on it explicitly. We can do that with some BATS set up easily enough (e.g. use tags or just skip the test if not on ECS).

filter_aws is this one: https://docs.fluentbit.io/manual/pipeline/filters/aws-metadata
I think the best option here is to spin up a dedicated test VM for it with Terraform and then skip the test unless we're on that VM. When we are on it then we can check the output of the example in the docs: https://docs.fluentbit.io/manual/pipeline/filters/aws-metadata#command-line

[patrick-stephens]

Let's move the common functions into the helpers file for BATS.
Let's then move the test scripts into BATS test functions we can invoke with the integration tests.

[leonardo-albertovich]

We can do that once I'm done with the PR but right now all I need are those three test cases, keep in mind that at the moment this was shared as a reference.