-
Notifications
You must be signed in to change notification settings - Fork 402
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.
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
[Featurerequest] Enable inmemory Report generation #957
Comments
I added two PRs to give you an idea what i mean with the featurerequest and how they could be implemented
|
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 |
@damianszczepanik Did you have any chance to take a look at the PRs? |
Briefly, so I have a few questions before deeper review:
|
-> Its an alternative/addition to the current solution.
-> could you comment on the PRs what you mean by that?
-> there should only be commented out code in PR 959, which is still a draft.
-> there should only be a few changes to the javadoc besides the changes that describe the new/changed functionality |
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:
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:
Because of that I have two Feature requests:
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
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.
The text was updated successfully, but these errors were encountered: