x/build: keep test result logs available after success

[dmitshur]

Currently, the x/build testing infrastructure (both trybots and post-submit builders) generally makes test logs available under two conditions:

• while the test is running, streamed
• after the test completed, if it failed

After tests complete successfully, the test logs immediately become inaccessible.

I don't know the exact rationale for this design, but my guess is that it done to reduce computational and storage resource use. It was likely deemed logs are less useful if tests passed. /cc @bradfitz Is there more context on this?

Feature Request

This feature request issue is to make them accessible on successful test completion for some amount of time (at least a month). Both on the build dashboard, and for trybot results.

The reasons for wanting this include:

• it's sometimes helpful to be able to know which tests ran and which tests were skipped, and to be able to confirm a specific test truly passed
• it's sometimes helpful to know which architectures were tested by trybots (and from that, to know which ones weren't), and having trybot result page with logs makes that much easier
• pretty much every CI system keeps test logs accessible regardless if tests succeeded or failed, so it has become a baseline expectation

I think this should be worth doing in order to improve the developer experience for people working on the Go project. Feedback from others is welcome.

/cc @golang/osp-team

[toothrot]

This sounds like it could be related to #13076 and #10313.

Edit by @dmitshur: Another related issue is #12669.

[bradfitz]

Agreed. Let's just keep them forever. They're small. We already keep the built artifacts after make.bash forever and they're way bigger.

History is because build.golang.org only had links for failures.

[dmitshur]

@toothrot Thanks for finding those issues. They support the decision to do this.

Both of those issues are from 2015 and talk about a subset of this problem, so I folded them into this higher level tracking issue. I think it'll be better for us to open new smaller issues as needed.

@bradfitz Thanks for providing background on this. @andybons has expressed his support for this too, so I think we're in favor of doing this.