Add loading state for slow build logs

[Flo4604]

When build logs are slow to load, the UI shows that something failed without making it clear that logs are still loading. Add a loading state or skeleton for the build log view.

[linear-code]

ENG-2836

[jaysomani]

I'd like to work on this.

[Flo4604]

Thanks for wanting to help, at the moment we’re not accepting external pull requests for this repo, so we can’t assign this issue for community contribution right now

We appreciate the offer though

[solomonerous]

Happy to pick this up. Planning a loading/skeleton state for the build log view so slow log fetches don't read as a failure - will follow the existing dashboard loading patterns.

[solomonerous]

Update after digging into the current dashboard code: the first-load case looks covered now - DeploymentBuildStepsTable wires isLoading into StreamingTable, which shows the column skeletons (skeletons.tsx) while the initial fetch is pending. The May screenshot predates that wiring.

The remaining gap is the background-refetch case: the build steps query polls every second (refetchInterval: 1000), and React Query's isLoading only stays true for the initial pending fetch. Once a poll has resolved with zero steps, a slow follow-up refetch leaves isLoading false and steps empty - so the table renders the 'No build steps found' empty state while logs are still loading, which reads as failure. That matches the spirit of this issue.

Proposed fix (small): thread buildSteps.isFetching into the table and swap the empty-state copy to 'Build logs are loading...' while a fetch is in flight and no steps have arrived - no skeleton flicker, since the empty state stays mounted and only the copy changes.

Before I ship that: is the refetch gap still reproducible on the current dashboard, or did the rewrites since May cover this on your side? If it still reproduces I'll have the change up quickly.

[Flo4604]

Hey Thanks for taking the time to look into this, but we currently do not accept external pull requests at this time.

[solomonerous]

Thanks for the clear response - understood, and I'll leave it with the team. The refetch-gap analysis in my comment above stands on its own in case it's useful whenever this gets picked up internally.