If the backend is down, it shouldn't prevent me to generate the project

Ideas
1

If the backend is down, it shouldn’t prevent me to generate the project:

tuist generate


✖ Error 
  You must be logged in to do this. To log in, run 'tuist auth login'. 

  Sorry this didn’t work. Here’s what to try next: 
   ▸ If the error is actionable, address it
   ▸ If the error is not actionable, let's discuss it in the Troubleshooting & how to
   ▸ If you are very certain it's a bug, file an issue
   ▸ Check out the logs at /Users/df/.local/state/tuist/logs/BA7CCD90-689C-4287-8B0D-2F9EFF00E0C9.log

If we don’t want to handle it automatically, we could at least have a CLI flag to skip the authenticated part

2

Similar to this, failing to upload the binary caches makes the tuist generate fail, which in turns makes the CI of a pull request fail.

I would consider to not make tuist generate fail also in this case

Storing remote binaries. Hold tight...
Uploading run metadata...
You can view a detailed run report at: https://tuist.dev/…monorepo/runs/1359487
✖ Error 
  The response from request to URL https://tuist-production.cc0237353f2f825680b0463629cd4a86.r2.cloudflarestorage.com/…/builds/… lacks the etag HTTP header
3

We only upload as part of tuist cache. I’d say that in those cases, it’s better to fail to highlight that tuist cache is not working properly. We recommend tuist cache to be run as part of main and not being a required job.

4

Makes sense for cache, the point of the first message about tuist generate still makes sense, right?

5

Yes, we should not fail on tuist generate when the server is down :+1: