[Featurerequest] Enable inmemory Report generation

[FloKaemmerer]

Hi,

I'm currently using this generator within a (Springboot)-Microservice that runs in EKS (AWS Elastic Kubernetes Service) which generates html Reports from cucumber-reports that are read from a S3 Bucket. The Reports are than again uploaded to a S3 Bucket.
But to do so I have to have a volume mounted for the service, which I would like to avoid.

Currently the generator uses heavily the volume:

• The input.json is read from volume
• Static resources are written to volume
• multiple directories are created
• html Files are written to volume
• Embeddings are written to volume

This is fine when you are running as a Jenkins Plugin that has a volume available anyway.

But when using the Generator within the service the typical workflow looks something like this:

• Read input from S3 (as byte[])
• Write input to volume as input.json
• Prepare output directory on volume
• Trigger generator with Input.json file
• (static resources, htmls and embeddings are written to the volume)
• Read htmls and embeddings as byte[]
• upload files to S3
• cleanup the volume

Because of that I have two Feature requests:

1. Trigger the generator with the input as a String, byte[] or List of Features.
   -> instead of passing a List of Strings (paths to the input files) to the constructor provide two methods:
   --> first takes the Paths
   --> second takes the json as String/byte[]/List of Features

2. Add an outputhandler to the generators configuration
   -> Default outputhandler writes the files to the volume
   -> Handler can be overwritten by a custom handler
   --> Custom handler could upload the files directly to S3 (or what ever the user wants), without writing them to a volume

I understand that the main usecase of the generator is the usage within the Jenkins Plugins.
But I believe by decoupling the generator from a physical volume it would openup a widerrange of usecases within a cloud environment.

[FlorianKaemmerer]

I added two PRs to give you an idea what i mean with the featurerequest and how they could be implemented

• Trigger the generator with the input as a String, byte[] or List of Features.
  -> Enable generation of Reports from a List of Features #959

• Add an outputhandler to the generators configuration
  -> Add output handler to configuration #958

[damianszczepanik]

Interesting feature but not very popular I guess so I'm not going to implement it. I will be happy to accept PR if you like add this feature. Ideally spited into smaller pieces to speed up review process

[FlorianKaemmerer]

I opened two PRs. Both are basicly the all you have to do to enable the feature.

It would be great if you could review them:

Add an outputhandler to the generators configuration
-> #958

Trigger the generator with the input as a String, byte[] or List of Features.
-> #959

[FlorianKaemmerer]

@damianszczepanik Did you have any chance to take a look at the PRs?

[damianszczepanik]

Briefly, so I have a few questions before deeper review:

• inmemory is an alternative or replacement for current solution
• later noise with changing import approach should be reverted
• later code which is not used should be removed, not commented out
• you can separate all changes related to javadoc and formatting (except imports) into separate PR which I will be happy to merge so then other PR will be smaller and easier to review

[FlorianKaemmerer]

Briefly, so I have a few questions before deeper review:

• inmemory is an alternative or replacement for current solution

-> Its an alternative/addition to the current solution.
The PR #958 adds a List of OutputHandlers to the configuration. By default it contains one Handler that writes the files to the volume. Therefore the default behaviour stays the same.
The User can add/remove handlers depending on their usecase.
The PR #959 is still a draft.
Same as the first PR it does not change the current behaviour but adds new posibilities for the user.

• later noise with changing import approach should be reverted

-> could you comment on the PRs what you mean by that?

• later code which is not used should be removed, not commented out

-> there should only be commented out code in PR 959, which is still a draft.
I was hoping for your thoughts on these snippeds of code.

• you can separate all changes related to javadoc and formatting (except imports) into separate PR which I will be happy to merge so then other PR will be smaller and easier to review

-> there should only be a few changes to the javadoc besides the changes that describe the new/changed functionality