github.com/abayer/test-infra@v0.0.5/docs/contributing-test-results.md (about)

     1  # Contributing Test Results
     2  
     3  The Kubernetes project welcomes contributions of test results from organizations
     4  that execute e2e test jobs.  This ensures we have coverage of Kubernetes on more
     5  platforms than just those that the Kubernetes project itself can fund or support.
     6  
     7  The process is as follows:
     8  
     9  - Designate a point of contact (github handle / e-mail / github team) that we can
    10    reach out to if needed (eg: mitigating flood/drought of data, assisting with
    11    migrations, etc)
    12  - Create a GCS bucket that is [world-readable](https://cloud.google.com/storage/docs/access-control/making-data-public)
    13  - Run e2e tests (we recommend using [kubetest](/kubetest/README.md))
    14  - Store test results in accordance with [Gubernator's GCS Layout](/gubernator/README.md#gcs-layout)
    15    - Unfortunately this part is currently left as an exercise to the reader. We use
    16      [bootstrap](/jenkins/bootstrap.py) to facilitate this and are in the midst of
    17      rewriting it to better support external usage.
    18  - Add the GCS bucket info to [buckets.yaml](/kettle/buckets.yaml) via a PR (use the
    19    previously designated github handle for the `contact` field).
    20  - Add jobs and dashboards to the [testgrid config](/testgrid/config.yaml) via
    21    a PR (use the previously designated point of contact info in a comment next to
    22    added `test_group`s, or even better in the `description` field for added
    23    `dashboard_tab`s)
    24  
    25  As of this writing, a good example GCS bucket to grep for in this repo would be the
    26  `k8s-conformance-openstack` bucket.
    27  
    28  We are actively working on improving this process, which means that this
    29  document may not be kept exactly up-to-date. Feel free to file an issue against
    30  this repo when you run into problems.
    31  
    32  We prefer test results that are actively kept up to date and maintained. This is
    33  especially true for testgrid, where stale dashboards clutter up the UI. We may
    34  periodically identify GCS buckets, jobs, or testgrid dashboards that have become
    35  more than 90 days stale and remove them via revertible PR.