The CI procedure involves cloning repos, so checking mtime will always produce a different value on each run, making it non-deterministic (i.e. successive runs will produce different values, thus change the same file’s output).
One solution to this would be to only rebuild pages with their commit log time. Successive runs would therefore use the committed time of the source file, and since the changes are only to the ‘last-modified’ time in the output (i.e. no change to the source in these auto-commits from the CI build process), there would be no change between the runs so no infinite loop.
One downside to this is in the case that the engine changes, I would expect this approach to mean that the CI build process would not reflect these changes (or rather only partially: only any source files which changed).
Another option would be to deliberately switch between these behaviours (selective vs. refresh all) based on some switch, e.g. it could be the pipeline trigger context.
lmmx
commented
2 years ago
The CI procedure involves cloning repos, so checking
mtimewill always produce a different value on each run, making it non-deterministic (i.e. successive runs will produce different values, thus change the same file’s output).One solution to this would be to only rebuild pages with their commit log time. Successive runs would therefore use the committed time of the source file, and since the changes are only to the ‘last-modified’ time in the output (i.e. no change to the source in these auto-commits from the CI build process), there would be no change between the runs so no infinite loop.
One downside to this is in the case that the engine changes, I would expect this approach to mean that the CI build process would not reflect these changes (or rather only partially: only any source files which changed).
Another option would be to deliberately switch between these behaviours (selective vs. refresh all) based on some switch, e.g. it could be the pipeline trigger context.