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.

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

Support for having large attachments saved externally to the report #281

Open
k02pradeep opened this issue Jan 18, 2024 · 5 comments
Open
Assignees

Comments

@k02pradeep
Copy link

🤔 What's the problem you're trying to solve?

Attaching images and videos in large reports is causing issue with build time and file size. Instead the images and videos can be stored in the known folder path and can be referenced by the report.

✨ What's your proposed solution?

Support for adding attachments should support passing urls for images and videos and have them referenced in the reports

⛏ Have you considered any alternatives or workarounds?

As the library does not support passing urls, other workarounds were not possible

📚 Any additional context?


This text was originally generated from a template, then edited by hand. You can modify the template here.

@k02pradeep
Copy link
Author

Issue in react component

@k02pradeep
Copy link
Author

As an alternative solution, adding mediaType text/html should be supported so that custom html content can be attached

@davidjgoss davidjgoss transferred this issue from cucumber/cucumber-js Jan 18, 2024
@davidjgoss davidjgoss changed the title Support for attaching images and videos using url/path instead of passing the binary data Support for having large attachments saved externally to the report Jan 18, 2024
@davidjgoss
Copy link
Contributor

davidjgoss commented Jan 19, 2024

cc @mattwynne @mpkorstanje @brasmusson @luke-hill, this feels like a problem we should solve.

In the messages schema for an attachment, we have the url property:

This field should not be set by Cucumber...It should be set by a program that reads a message stream

This seems right to me, and I think the formatter is the program that transforms the attachment message. So something like this might work:

  • The formatter has an option to externalise certain attachments by some criteria (type/size/whatever)
  • The formatter is given a reference to the directory path (assuming the output stream is to a file)
  • The formatter deals with creating the attachment files and transforming the messages that go to its own output stream
  • Other formatters are unaffected - they still get the canonical stream of messages with attachment content inlined as base64 - and can make their own design decisions

This seems plausible in JS land, I'm not sure about the others though, what do we think?

@vitalets
Copy link

Example of such externalization that is done by cucumber-html-reporter.

@mattwynne
Copy link
Member

mattwynne commented Jan 21, 2024

Yeah that seems sensible @davidjgoss.

One of the original ideas of this message protocol was that we could use a kind of "unix pipes" approach to composing behaviour by attaching little programs to the stream in a chain. We can probably conceive of this responsibility to "unpack" the attachment message bodies as files in a directory, then forward on messages with URLs to those files, as a discrete responsibility. We could potentially build it in a separate polyglot repo if we're going to need different language implementations, with its own set of tests, then pull it into the formatters.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants