Support for comparing bundle size across PRs in CI pipeline

Ideas
1

Hi Tuist team :wave:

We’ve recently started using the Tuist Bundle feature and it’s been very helpful for tracking our bundle sizes, thank you for the great work!

We’d like to take this a step further and introduce alerts for significant bundle size increases at the PR level, within our CI pipeline.

Here’s our use case:

  • During each CI run, we want to upload the current bundle and immediately fetch its size.
  • Then we want to compare it with the previous bundle size.
  • If the difference exceeds a defined threshold, we would trigger a warning or fail the build.

Currently, it seems like:

  • The POST /bundles API endpoint only returns the new bundle ID and URL.
  • There’s no easy way to fetch the previous bundle size via the API.

We were wondering if this is something that could be supported either via:

  • The REST API, by exposing the previous bundle size, or
  • Enhancing the tuist inspect bundle CLI command to provide this kind of information.

Happy to elaborate more or iterate together on the best solution. Thank you again!

Best,
Ilayda

2 Likes
2

Hi @ilaydasahinn,

We don’t support validation against a baseline yet, but it’s something we are definitively interested in supporting. Until then, we are going to add a GET endpoint that you can use to get this information through the API.

3

Just a GET endpoint for retrieving a bundle by ID is not enough – as you also need a baseline to compare the bundle with.

There are two ways to do this:

  • Add a GET /bundles endpoint that will allow you to retrieve the latest bundle for a given branch (usually main). That endpoint could be used to retrieve arbitrary list of bundles, too
  • Include the last_bundle as part of the Bundle schema, so it’s returned both when getting a detail of a bundle and when the bundle is created

While with the former you’d need to make two API calls to get the delta of bundle sizes, I think it’s better not to include the last bundle directly in the Bundle schema to keep that schema simple and flat.

Once we have those endpoints, we can add the capability directly to the CLI. To error out the tuist inspect bundle command when a threshold is crossed, we could either:

  • Add an explicit argument in the CLI, such as: tuist inspect bundle App.ipa --error-threshold-percentage 80
  • Add a setting in the dashboard to set the threshold in the dashboard. We could retrieve the threshold by adding a new endpoint, such as /projects/:account_handle/:project_handle/settings and the CLI would then fetch the value and error out if crossed

If we do the latter, the POST /bundles endpoint could already include whether a threshold was crossed, but again, we’d be adding bundle comparisons in the GET /bundles/:id endpoint which I’m not sure I’m a fan of.

I think I’m personally leaning to:

  • Adding a GET /bundles endpoint, along with a GET /bundles/:id endpoint
  • Adding project settings in the dashboard and set the threshold there
  • The CLI would compute the bundle size delta between the new bundle with the latest bundle and check whether it’s over the project’s set threshold.

It does mean we’d be adding some extra business logic to the CLI that could be offloaded to the server, but it would allow us to keep our endpoints more straightforward.

@pepicrft @cschmatzler wdyt? :thinking:

4

Onboard. For the route to get the bundles, we can add git_branch as filtering attribute, and created_at/inserted_at as a sorting one.

I wonder if we should also consider adding an easy way to get an account-scoped token, like you can do for example on GitHub.

5

Certainly. We generally need to refactor our endpoints to support account tokens – right now, the account token supports just reading from the registry and project token doesn’t have access to most new endpoints. So, teams can’t really use our API for automating their flows.

Cool :+1: We can make sorting by inserted_at as the default as that feels sensible. But having the ability to sort by specific fields is still a need regardless.

6

Thanks for your helpful suggestions :rocket:

While reviewing how we could adopt it in our setup, we came across a specific case we’d like to ask about:
In our workflows, we plan to push bundle size metrics for the same branch under two different build conditions:

  • For test packages intended for installation on physical iOS devices
  • For debug builds used in simulator-based pipelines

Since both uploads would be tied to the same branch name, we’re wondering:
We were wondering if it would be possible to also filter bundle metrics by platform?

And for now, we are planning to query these metrics through the API, but if similar filtering options become available via the CLI in the future, that would be a great improvement as well :pray:

7

Yeah, that shouldn’t be a problem :+1:

1 Like
8

Started agentic-coding this one here. I should have it before the end of the week or early next one.