Need/problem
When CLI issues occur, it’s important that developers have an easy way to debug what has happened – and to be able to provide the Tuist team with the necessary context.
We’ve already done a great step in that direction by storing log files in the file system and we surface the path when an error occurs. However, this is still not perfect:
- The log file is not accessible when the error occurred on the CI – in that case, developers would need to upload the Tuist state directory as an artifact.
- Developers need to copy and reupload the log file when sending the logs to their colleagues or to the Tuist team – another point of friction.
Detailed design
To fix these friction points, I’m proposing to upload the logs automatically when an error occurs.
The steps would be as follows:
- Error occurs
- The logs file is stored on disk (already implemented)
- The logs file is zipped and uploaded to the Tuist storage in a conventional path based on the run (command event) id.
As of now, we wait for the upload of run analytics on the CI – so, we’d additionally wait for the logs to be uploaded as well before posting the link to the run detail.
Locally, we stop the execution without waiting for the run detail to be uploaded, so we don’t prolongue the execution of the CLI in interactive environments and instead upload the analytics in the background as part of a future execution. That does mean, however, we can’t immediately post the link to the run detail with the logs.
To upload the run along with the logs, we can either:
- Keep things as-is – we only show the local path and the logs would be uploaded sometime in the future.
- Add a new command to upload the latest run in the local queue – such as
tuist analytics update
While not being directly to this RFC, I’d also propose to remove the system of event queues and instead upload the events in the background as we do for inspecting builds. That way, upload of events doesn’t depend on developers running another Tuist command.
Drawbacks
The logs can be potentially quite large – size of >100 MBs of the zipped logs would probably be not out of the ordinary. That does mean increased costs for our storage and some additional time spent on the CI to finish the upload of the logs. I’d argue the benefits outweigh these cons, at least on the CI.
Unresolved questions
I’d argue that the CI flow is certainly a good improvement. As for the local environment, I’m not sure if uploading the logs in the background or with a dedicated command would improve the flow a lot as opposed to sharing the file from disk directly with colleagues or the Tuist team.
@vojtechvrbka mentioned that Develocity has something similar – would you mind looking at how they deal with failures in local environments?