Our developers (new to buildkite UI) are getting confused about how to find failure causes in the logs. We are working on cleaning up the logs, but also starting to use annotations to surface the info in a more easy-to-see place. However, the fact that annotations for all steps show up at the top makes it harder to discover.
Example: When unit tests fail, it would be nice if unit test results & useful links could show up next to the unit test job.
This specific UX problem is probably the single largest contributor to our current support burden. No one scrolls up to look for annotations and even if they did they lose context in doing so. Surprised this does not have more attention.
The current thinking is that the most recently generated annotation is likely the most relevant and actionable, so it should be at the top. But it’s true that this is not ideal, and we’re exploring ways to offer more context within a build and more tools to present and interpret that information. It’s in our backlog but we don’t have any timeframe at the moment.
I’m surprised that is the thinking. If you are filling out a long web form, would you expect all your errors to be bunched at the top of the page, potentially hidden above the fold if you’ve scrolled down? Or would you expect errors next to the field that has the error?
most relevant and actionable, so it should be at the top
By this logic I would expect the most recent/currently processing step in the pipeline to be at the top of the page not the bottom, but that is not the case.
Anyway, thanks, we will figure out some sort of workaround in the meantime.
--job value #
Which job should the annotation come from
Environment variable: $BUILDKITE_JOB_ID
Otherwise what does --job actually do? I added it and cannot tell how it links the annotation to the job at all. No link shows up and the annotation sits at the top of the build page.
Hi Ian,
Thanks for your insights! You’re absolutely right—currently, if you specify --job=$BUILDKITE_JOB_ID, it will not affect where the annotation appears in the UI. While the annotation is internally associated with the specified job, it still displays at the top of the build page rather than being visually linked to the job itself.
Effectively, this makes specifying the current job ID a no-op in terms of UI placement—it runs but doesn’t produce the expected visual effect. We’ll update the documentation to make this clearer.
That said, you can use --job=… to indicate which job the annotation should be considered created by, and therefore which build it should be displayed on. One possible workaround is passing the triggering job ID ($BUILDKITE_JOB_ID) through an environment variable or metadata, then using it when creating your annotation in the triggered build.
Thanks,
Yes - We’ve had a few requests to have the annotations appear on the job itself and it is something that we are looking at adding. There’s no timeline for it yet but it would be great to have!