Skip to content

Files

Latest commit

c8554b1 · Aug 11, 2020

History

History
This branch is 28450 commits behind kubernetes/test-infra:master.

gubernator

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
Oct 3, 2019
Feb 19, 2019
Mar 29, 2019
May 20, 2016
Jan 9, 2018
Oct 12, 2018
Jun 3, 2018
Jul 20, 2020
Jun 1, 2020
May 5, 2016
Jan 9, 2018
Aug 26, 2016
Aug 11, 2020
Sep 6, 2016
Jan 26, 2018
Mar 4, 2019
Mar 4, 2019
Feb 27, 2018
Feb 27, 2018
Feb 28, 2019
Apr 10, 2019
May 5, 2016
Feb 9, 2018
May 16, 2017
Jan 23, 2019
May 18, 2017
May 16, 2017
Oct 23, 2018
Dec 20, 2018
Dec 8, 2017
Aug 26, 2016
Jan 15, 2019
Jan 14, 2019
Sep 5, 2017
May 18, 2017
Jan 9, 2018
Feb 22, 2018
Aug 26, 2016
Jul 6, 2020
May 17, 2018
Mar 23, 2018
Jul 20, 2020
Jul 6, 2020
Sep 18, 2019
Jan 24, 2018
Aug 26, 2016
Dec 27, 2018
Dec 27, 2018
Dec 8, 2017
Apr 12, 2018
Mar 30, 2018

Gubernator is a frontend for displaying Kubernetes test results stored in GCS.

It runs on Google App Engine, and parses JSON and junit.xml results for display.

https://gubernator.k8s.io/

Adding a repository to the PR Dashboard

To make Gubernator's PR Dashboard work on another repository, it needs to receive webhook events.

Go to Settings -> Webhooks on the repository (or organization) you want to add.

Add a new webhook with these options:

Payload URL: https://github-dot-k8s-gubernator.appspot.com/webhook Secret: Ask test-infra oncall. Select: "Send me everything"

Gubernator will use the events it receives to build information about PRs, so only updates after the webhook is added will be shown on the dashboard.

Development

Deployment

  • Visit /config on the new deployment to configure GitHub OAuth logins and webhook secrets.

GCS Layout

In order to correctly interpret jobs results, in GCS, Gubernator expects that any one job directory is laid out in a specific manner, and that job directories are laid out in a specific manner relative to each other.

Job Artifact GCS Layout

Every run should upload started.json, finished.json, and build-log.txt, and can optionally upload JUnit XML and/or other files to the artifacts/ directory. For a single build of a job, Gubernator expects the following layout in GCS:

.
├── artifacts         # all artifacts must be placed under this directory
│   └── junit_00.xml  # JUnit XML reports from the build
├── build-log.txt     # std{out,err} from the build
├── finished.json     # metadata uploaded once the build finishes
└── started.json      # metadata uploaded once the build starts

The following fields in started.json are honored:

{
    "timestamp": "seconds after UNIX epoch that the build started",
    "pull": "$PULL_REFS from the run",
    "repos": {
        "org/repo": "git version of the repo used in the test",
    },
}

The following fields in finished.json are honored:

{
    "timestamp": "seconds after UNIX epoch that the build finished",
    "result": "SUCCESS or FAILURE, the result of the build",
    "metadata": "dictionary of additional key-value pairs that will be displayed to the user",
}

Any artifacts from the build should be placed under ./artifacts/. Any JUnit XML reports should be named junit_*.xml and placed under ./artifacts as well.

Test Properties [Optional]

Test properties are a set of key value pairs defined on the test case and are optional. The test result file junit_*.xml contains a list of test cases and the properties associated with it. These properties can be later parsed by any aggregator like testgrid, and used to collect metrics about the test case.

The properties can be defined as:

<testcase ...>
  <properties>
    <property>
        <name>key1</name>
        <value>value1</value>
    </property>
    <property>
        <name>key2</name>
        <value>value2</value>
    </property>
  </properties>
</testcase>

GCS Bucket Layout

In your bucket, a number of directories are required to store the output of all the different types of jobs:

.
├── logs                    # periodic and postsubmit jobs live here
│   └── other_job_name      # contains all the builds of a job
│      ├── build_number     # contains job artifacts, as above
│      └── latest-build.txt # contains the latest build id of a job
└── pr-logs
    ├── directory                # symlinks for builds live here
    │   └── job_name             # contains all symlinks for a job
    │       ├── build_number.txt # contains one line: location of artifacts for the build
    │       └── latest-build.txt # contains the latest build id of a job
    └── pull
        ├── batch                # batch jobs live here
        │   └── job_name         # contains all the builds of a job
        │       └── build_number # contains job artifacts, as above
        └── org_repo                     # jobs testing PRs for org/repo live here
            └── pull_number              # jobs running for a PR with pull_number live here
                └── job_name             # all builds for the job for this pr live here
                    └── build_number     # contains job artifacts, as above
                    └── latest-build.txt # contains the latest build id of a job

Migrations

  1. 2018-01-09: GitHub webhook and oauth secrets must be reconfigured. Visit /config on your deployment to enter the new values.