Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[Featurerequest] Enable inmemory Report generation #957

Open
FloKaemmerer opened this issue Aug 12, 2020 · 6 comments
Open

[Featurerequest] Enable inmemory Report generation #957

FloKaemmerer opened this issue Aug 12, 2020 · 6 comments

Comments

@FloKaemmerer
Copy link
Contributor

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
Copy link

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

@damianszczepanik
Copy link
Owner

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
Copy link

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
Copy link

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

@damianszczepanik
Copy link
Owner

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@damianszczepanik @FloKaemmerer @FlorianKaemmerer