testgrid results not appearing for (new) federated test results

[justinsb]

I am populating this bucket with federated test results:
https://console.cloud.google.com/storage/browser/kopeio-kubernetes-e2e/logs/kubernetes-e2e-aws

I believe they should now appear here: https://k8s-testgrid.appspot.com/kopeio#kopeio-aws and the gubernator link goes to the right place. But while the job is updating, results are not appearing.

Can someone check the logs from testgrid?

[justinsb]

The build ids follow this pattern, BTW: 20170904-021830-ad26a7c7-7722

I think that is this pattern: https://github.com/kubernetes/test-infra/blob/master/jenkins/bootstrap.py#L651-L655

But I may have got the wrong pattern or maybe this pattern isn't yet implemented in testgrid?

[luxas]

Why not 1, 2, 3, 4, ...?

[justinsb]

Because it's a distributed system 😀

[luxas]

Heh, indeed 😜

[justinsb]

Inspired by @luxas I sent through a test with build id = 12345 and that did show up.

What are the valid values for a build id? Can we publish the testgrid source, even if it is read-only?

[krzyzacy]

build number is the subdir name and need to be numerically increasing

[michelle192837]

To the source-publishing question; to my understanding, we can't, no.

[krzyzacy]

But hopefully we will rewrite an open-sourced version of client in the near future.

[justinsb]

@krzyzacy can I use YYYYMMDDHHMMSS or will that be too big?

I mentioned it in the meeting, but even if it isn't true open source (i.e. you can't accept contributions), and even if it is a partial snapshot, it would have a lot of value to people in figuring out this stuff or in helping to build testgrid v2.

[krzyzacy]

@justinsb I think it need to fit into an int (?) - so basically testgrid caches the largest processed build id, and next time it will skip once it hits a build id smaller/equal to the largest processed build id.

For second part, I cannot make the call, <----- @fejta

[krzyzacy]

I'll close this issue, we can move the opensource discussion to #3323