Skip to content

Conversation

@pietroalbini
Copy link
Member

To help triage and handle flaky tests, it was suggested in the control plane huddle a few weeks ago to setup Trunk's flaky test detection. We run tests on Buildomat though, which doesn't support setting the secret to authenticate with Trunk.

To work around the issue, I created a new script to upload all the relevant metadata to Trunk given the GitHub Check Run ID of a Buildomat job:

tools/upload_buildomat_junit_to_trunk.sh <github-check-run-id>

The script is also hooked up to a GitHub Actions job that runs after every completed Buildomat job. Note that if jobs change names or are added the case block in the script will need to be updated.

@pietroalbini
Copy link
Member Author

Before this can be deployed a secret needs to be configured. I'll work with Augustus to set things up, please hold off on merging for now :3

@pietroalbini
Copy link
Member Author

This is ready for review!

Copy link
Contributor

@sunshowers sunshowers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice!

Comment on lines +47 to +55
# Determine whether this comes from a PR or not. It's load bearing that we detect things correctly,
# since Trunk treats PRs vs main branch commits differently when analyzing flaky tests.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting!

commit="$(jq -r .head_sha api/check_run)"
github_app="$(jq -r .app.slug api/check_run)"
job_url="$(jq -r .details_url api/check_run)"
pr_url="$(jq -r .pull_requests[0].url api/check_run)"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can there be multiple PRs attached to a check run?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes.

PRs cannot be attached to check runs. Instead, GitHub tries to look for PRs that contain the branch being tested, and includes them in the API response. From their docs:

Pull requests that are open with a head_sha or head_branch that matches the check. The returned pull requests do not necessarily indicate pull requests that triggered the check

In practice, if there are multiple PRs returned by the API this will show in the Trunk UI just the information of the first one. I don't think it's the end of the world though, I don't expect it to happen much.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh weird. thanks, should be okay in that case -- might be worth putting in a small comment explaining this.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a comment!

Comment on lines 56 to 57
# For PRs from outside forks the GitHub API doesn't return the PR linked to the commit, nor the
# branch name. In that case, assume it's an unknown PR and use placeholders.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lol...

hmm, I wonder how many folks are doing this -- what happens in this case? Does Trunk recognize this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding is that Trunk doesn't gather any metadata about the commit on its own. Rather, it fully trusts what the CI provider tells it, so in the case of this script what we set in the environment variables.

In Trunk this will appear as the placeholders we configure in the script:

image

Comment on lines +84 to +95
echo "unsupported job name, skipping upload: ${job_name}"
exit 0
;;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this check be moved to the top?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It has to happen after the check_run API request (since it retrieves the job name from it). I can move it to happen just after that request, but stylistically I opted to do all API requests first. If you prefer I can move it up though.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I guess I found it to be a little strange that we're doing all these extra requests for a check run we'll not process. I'd personally move it to right after the check_run request but feel free to make the call here.

commit="$(jq -r .head_sha api/check_run)"
github_app="$(jq -r .app.slug api/check_run)"
job_url="$(jq -r .details_url api/check_run)"
pr_url="$(jq -r .pull_requests[0].url api/check_run)"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh weird. thanks, should be okay in that case -- might be worth putting in a small comment explaining this.

Comment on lines +84 to +95
echo "unsupported job name, skipping upload: ${job_name}"
exit 0
;;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I guess I found it to be a little strange that we're doing all these extra requests for a check run we'll not process. I'd personally move it to right after the check_run request but feel free to make the call here.

@pietroalbini pietroalbini merged commit 200ce2d into main Sep 22, 2025
17 of 22 checks passed
@pietroalbini pietroalbini deleted the ea-buildomat-trunk branch September 22, 2025 18:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants