PathRef: Is it possible to tell, if an upstream task result was cached or "executed"?

[Quafadas]

I'm spending some time going deeper on mill... and enjoying myself. My hobby has been a static site generator that uses scala3's scaladoc (which I'm coming to like, up to a few quirks), not important for this question, but here for anyone interested.

https://github.com/Quafadas/mill_scala3_mdoc_site

I'm quite happy with it, up to the fact, that "live reload" is janky. I think the reason for this, is the default delete-and-recreate when upstream tasks are "invalidated" (forgive me if the nomenclature is poor) breaks any third party "live reload" mechanism.

The way I set this plugin up (for better or worse), is that scaladoc runs twice. Once to generate the API (slow) and once to generate your actual docs (fast) on the assumption, that most of the doc-edit loop, is spent in actual .md files. Now we get to the meat of curiosity driven over-engineering. To manage this "run-twice loop" and get the most out of "live reload";

1. If the "API-doc" hasn't hasn't changed (i.e. that task is run out of the cache), then do nothing, otherwise delete and re-create all files.
2. Diff the "docs-only" task to previous and "patch diff" it

I guess, that I can do 2. with inspiration from this discussion;
#2750

Which lead me to read the sourcecode for PathRef. Am I correct, that I could use a "fast" PathRef, which by default would collect and hash the modified timestamps of all files in it's out folder? I could then check that single hash against a cache of that held in out directory in the downstream task?

In combination with T.Persistent, Is that the "canonical" strategy for detecting whether a task has been invalidated and has changed outputs?

[lihaoyi]

I think what you describe would work. I don't think it needs to be a fast pathref though? A normal pathref with a content-based hash would work too: save the content hash in your dest folder, compare against it each time the task runs to determine if it has changed

[lihaoyi]

But yes, it does seem you want to keep things around on disk between runs of the task, and manage some kind of finer-grained invalidation logic yourself. That is precisely what T.persistent is meant to be used for

[Quafadas]

Got it working, many thanks for the response :-).