@chelkyl is attempting to deploy a commit to the Vercel Team on Vercel.

A member of the Team first needs to authorize it.

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/vercel/turbo-site/7pfU5uTjoYPiEEUqaf1p9z6JzJdT
✅ Preview: https://turbo-site-git-fork-chelkyl-add-logs-command.vercel.sh

I am liking this idea :)

@chelkyl can you say more about your use case for this command? I think we would like to avoid having hashes leak into the UX to the extent possible, so maybe there is another way to address the particular content you are interesting in replaying?

@gsoltis This command was to address dcherman's comment. The original request was for some way to view the logs that were hidden if you run with --output-logs=new-only. Over time, I expanded the scope to add some very minor task history querying capability, restrict output to the hashes you specify, show more data about the tasks, sort the output, and format the output.

I would understand if this isn't a compelling use case!

I can definitely see the utility in getting the logs for tasks that were run. I think the challenge is going to be in finding a good way to address them.

I like the idea of tracking recent runs. That could tie in nicely with eventual better management of the cache. I also like the idea of supplying the same arguments to turbo logs that were supplied to turbo run, along with the particular tasks of interest (web#build, api#test, etc.) to replay those logs, or an appropriate message on a cache miss.

Agreed! The hash seemed to be the best solution, especially because the cached log folders are named by their hash.
However, it would be great to support task names (in addition to hashes?), since I could include task globbing.

How do you think task names support should be implemented? My initial thought is to add another file like the last run log that is just a JSON file mapping task name to hash that is only added to during turbo run.

I think having each turbo run produce a manifest would be a good idea, and I think @nathanhammond was interested in something like that as well. Maybe the way to go about this is to start an RFC for what that file should look like, and then the logs command would read those to find log files?

Heya @chelkyl! @gsoltis is 100% correct about my opinion. I believe that each run should produce a unique identifier that can be used to go back and look up what happened. Conceptually, turbo run => ID => look up individual task logs and caches. In my imagination all of the identifiers would be opaque hashes, possibly excepting some (ignored) portion of the identifier for the run that encodes the start time, or a specified name. (Time would only be for monotonic sorting on a single box, not for absolute time. Any name would just be a human-readable prefix/suffix. Both would be ignored by the program.)

I see! I hadn't even considered uniquely identifying, storing, and isolating each turbo run call.
How would the id hash be generated? Would it be a hash on all of the tasks or their hashes for that run?

@chelkyl If we aren't using it for a cache hit, which I think we wouldn't be, you could use a uuid. A nice-to-have feature would be something easily time-sortable.

This one's looking a little stale, folks. Seeing as we're nearly complete with our Rust port, I'm going to close this out as this would shortly end up being deleted code if it were to land.