feat(proposal): native test report integration#1022
feat(proposal): native test report integration#1022timhuynh94 wants to merge 10 commits intomainfrom
Conversation
wass3rw3rk
left a comment
There was a problem hiding this comment.
just first round of feedback. i might do a separate one for Details section which looks pretty good, but want to review more closely. Will probably just respond as comments instead of reviewing PR.
| Provide your description here. | ||
| --> | ||
|
|
||
| * Currently, there is a lack of native support for handling, visualizing, and tracking test results across builds. Inspired by the feature set in Projektor.dev, this proposal aims to add a dedicated, native support `test-report` feature to Vela.This feature will allow users to parse, store, and visualize test results in a more user-friendly manner. |
There was a problem hiding this comment.
maybe as part of the description it would be appropriate to list out similar capabilities from other CICD systems, here's a couple of examples:
- https://docs.semaphoreci.com/using-semaphore/tests/test-reports
- https://circleci.com/docs/collect-test-data/
- https://docs.travis-ci.com/user/uploading-artifacts/
- https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/storing-and-sharing-data-from-a-workflow#uploading-build-and-test-artifacts
- https://docs.gitlab.com/ee/ci/testing/unit_test_reports.html#how-to-set-it-up
- https://buildkite.com/docs/test-engine/ci-environments
- https://codefresh.io/docs/docs/testing/test-reports/
alternatively, this could also be represented in the "Why is this required?" to support that section.
Co-authored-by: David May <49894298+wass3rw3rk@users.noreply.github.com>
Co-authored-by: David May <49894298+wass3rw3rk@users.noreply.github.com>
using your implementation phases as a guide, what about the following order:
In terms of chunks of work and adding incremental value, those phases seem appropriate. Phase 1 is pretty heavy, so i pulled UI out and turned that into two phases for the whole effort and combined some points. There probably could be more detailed subsections within each phase but at a high level, what do you think? You will notice that I dropped the Slack integration part. I think this could be a bigger play and separate effort to integrate native ways of triggering notifications, not limited to Slack or this test reporting feature. In the meantime, there are ways to leverage something like the Slack plugin today, I think. |
|
As discussed within Slack, it would be nice if the storage pattern developed as part of this approach could be re-usable to enable future use-cases similar to GitHub Actions artifacts. |
|
didn't see it linked here, but #43 should probably be associated with this. |
In this proposal, there 2 approaches being proposed for native test-report step.