Proposal: Add optional attachment size
Context
In our private allure2 fork, we use the source field of attachments not only for file paths but also to support data:, http:, https:, and file: protocols. Basically, remote-hosted attachment files (or JSON-only allure-results with no binary ballast).
While this works quite well, an optional size property would be extremely helpful for remote attachments — it would eliminate the need for HTTP roundtrips using HEAD requests just to retrieve Content-Length when generating HTML reports.
I wonder, can we find common ground here and consider making this part of the standard?
Checklist
- [x] Sign Allure CLA
- [ ] Provide unit tests
For more context.
I meant the extra roundtrips here: https://github.com/allure-framework/allure2/blob/main/allure-generator/src/main/java/io/qameta/allure/DefaultResultsVisitor.java
@Override
public Attachment visitAttachmentLink(final URL attachmentLink) {
final RandomUidContext context = configuration.requireContext(RandomUidContext.class);
return attachmentLinks.computeIfAbsent(attachmentLink.toString(), file -> {
final String uid = context.getValue().get();
final String fileName = attachmentLink.getFile();
final String source = attachmentLink.toString();
final Long size = new UrlSizeChecker().getContentSize(attachmentLink);
return new Attachment()
.setUid(uid)
.setName(fileName)
.setSource(source)
.setType(WILDCARD)
.setSize(size);
});
}
If you are interested in backporting size to allure2 Java generator, I could provide the cherry-pick from the fork.
I don't see any concern there. Until the parameter is optional, the user decides, which size value should be used in the attachment. @delatrie what do you think?
Well, I have not looked for that in allure3, but if you want some basic implementation there too, I might look into it.
@baev, thanks much! 🙏 Could you look also into: https://github.com/allure-framework/allure-java/pull/1182 ? They are related.