I would also like to express my interest in this feature. We have a lot of testrail automation in our company but not being able to attach our screenshots to the results using the API is a big hindrance.
Happy to add another vote, thanks Aaron!
I am also adding my ‘vote’ to this - uploading attachments through the API would be a really useful feature to have.
Thanks for your feedback, Petter!
We are updating our automated test runs via the API and would really love the ability to attach logs and error output from CI directly to a failed test case. It would make triage, locating, and discussing issues to later be pushed out to bug tracking so much simpler.
Thanks for your feedback, happy to add another vote!
Any idea if this feature will be implemented anytime soon. Ability to upload attachment or image would make things so much easier
Thanks for your feedback! We currently don’t an estimate unfortunately and recommend uploading attachments to an external location and then including a link in the result description (or embedding the image directly), for example.
Another +1 here.
Coming up on 5 years since the initial request, along with the multiple posts asking for the same feature. Is there any hope of this feature being implemented? I know that we can upload attachments to an external location and link to them but that gives us more to manage and then Testrail is no longer our one stop solution. Attachments are a big part of our workflow and we would love to see this implemented.
Thanks for your feedback. Yes, it’s definitely still planned to look into this. The initial request/thread here was still for the old API and we introduced a new completely new API a few years later and we would like to support attachments eventually with the new API.
Is there an estimated completion date on this?
There’s currently no estimate/time frame at this point but we understand that this feature request is important to many customers and it’s definitely planned to look into this.
I just wanted to offer a brief counter-point to this feature request. I too was initially searching for a way to add attachments to test results via the API. But after some consideration, I now think it is far better to put would-be attachments on a secure web or file server – under the full control of the TestRail user’s organisation – and then put a link to the file in the test result. Let me explain.
Think about how test result attachments are, or would need to be, implemented. Either:
The attachments are stored in the back-end database as binary blobs or encoded text. This increases the size of the back-end database, and MySQL isn’t the right kind system for storing large amounts of binary data.
The attachments are stored on the TestRail server file system, or SAN connected to the server. This will make migrating databases difficult, and add complexity to the server architecture and components.
It’s fine to have the ability to add an attachment manually, because you’re unlikely to get a large number of attachments that way. But if a process is using the API, it’s probably an automated system with the ability to quickly generate large amounts of data. QA staff – we’re generally careful and contentious people – will want to store as much test data as possible, and keep all of it forever.
I want the Gurock brothers focused on building new test-specific features in TestRail, not dealing with corrupted, overloaded databases, or managing terabytes of stale data that no-one will ever look at. The ability to add attachments via the API will increase costs for all users, take attention away from genuinely useful features, and has serious potential to decrease system stability, increase bandwidth, degrade performance, and introduce security issues.
Tobias and Dennis, please do not add the ability to upload attachments to test results. Superficially, it does seem like a good idea, but it has the potential to become a nightmare, or disaster, for everyone.
As suggested in a reply above, it is best to upload test artefacts to a separate server directly under the user’s control, such as a corporate local file server, web server, SharePoint server, or even Dropbox account – then include a link in the test result comments. The linked files can still be accessed directly by the people using TestRail. The TestRail user’s organisation maintains full control over the artefacts.
Let’s keep TestRail focused, lean, and great.
Thanks for your feedback, Steve Yes, that’s also one of our concerns and we also think that uploading attachments to an external location (especially with test automation) is a really good option. It also makes tasks such as taking backups easier for many environments if you store data in a central location. Uploading attachments via the API is definitely not off the table but we also need to think about scalability with TestRail Cloud which already deals with TB of data (even without API attachment support). Attachments, files and reports are stored outside the database by the way (on the file system instead) and this is true for both TestRail Cloud and Server.
Attachments are already are stored on a disk accessible to the server. Regardless of the number of attachments on your TestRail server you would be crazy not to implement a backup strategy.
Depends what you call “large”. Our instance (which we can only add attachments to manually given the lack of an API) has over 32,000 attachments in it after some 4 and a bit years of usage.
Are you assuming that everyone is using the cloud hosted TestRail instances? We are self-hosted and manage our own infrastructure.
No, it is not “best” to do this. It’s a workaround. Do you think JIRA encourages users to do this? No, they provide an API to do this - and yet they are not falling over due to decreased performance / stability / etc.
The workaround adds additional load to the organization as we would need to backup 2 separate locations.
The workaround could also require the organization to reimplement the user access control provided by TestRail, depending on the sensitivity of the data.
The API requested for in this feature request is aimed at allowing those organizations who can deal with the infrastructure requirements of having thousands of attachments to be more efficient in their workflows.
+1 on support for creating attachments via API.
Thanks for your feedback, Igor!
- my vote for this feature.
This is the only implementation pending from my side. Awaiting for the next release of the API’s having this uploading/downloading attachments.
Thank you for the post. This is in fact at the top of our feature list as we have quite a few customers that would benefit from this feature. Keep an eye out on this post or on our blog for updates.
I would like to see this feature implemented.