Implement get_file_hash

[dancek]

WARNING: contains a bug.

As mentioned in #519, both the cachebust commit I previously posted and this one look for static files directly in content_path when they're really in static/. I'll fix that tonight if I have time.

EDIT: it's fixed now, in the first commit.

---

IMPORTANT: Please do not create a Pull Request adding a new feature without discussing it first.

The place to discuss new features is the forum: https://zola.discourse.group/
If you want to add a new feature, please open a thread there first in the feature requests section.

Sanity check:

• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Code changes

(Delete or ignore this section for documentation changes)

• Are you doing the PR on the next branch?

If the change is a new feature or adding to/changing an existing one:

• Have you created/updated the relevant documentation page(s)?

[dancek]

This is now two commits, with the first one fixing my previous blunders with cachebust. I erroneously read files from content_path when static files actually are in static_path.

The implementation has different functions compute_file_sha256, compute_file_sha384 and compute_file_sha512 for different hash types, which looks a bit repetitive and dumb.

Another option is to make the calls like compute_file_hash<Sha256>, but that requires a complicated trait bound to the function:

fn compute_file_hash<T>(path: &PathBuf) -> result::Result<String, io::Error>
where
    T: Digest + io::Write,
    <T as Digest>::OutputSize: ops::Add,
    <<T as Digest>::OutputSize as ops::Add>::Output: generic_array::ArrayLength<u8>
{
    let mut file = fs::File::open(path)?;
    let mut hasher = T::new();
    io::copy(&mut file, &mut hasher)?;
    Ok(format!("{:x}", hasher.result()))
}

That would also add a direct dependency on generic_array (though sha2 depends on it anyway). I'll switch to that version if you prefer it. I just thought it's better to err on the side of readability in a FLOSS project.

Also, let me know if you'd rather have a separate PR and possibly a bug report for the first commit.

[dancek]

Oh boy, the cache-busting is still broken on generated assets (compiled scss).

[dancek]

Ok, the final try. Both the cachebusting implementation and get_file_hash will search in static_path, output_path and content_path. If none of them works, cachebusting reverts to timestamp and logs a warning to stderr. I realized it's annoying to crash just because cachebusting couldn't be done in the best possible way.

Hope this is good.

[dancek]

Oh, build_timestamp was removed after I branched from next. Let's error out if the file is not found, then.

[dancek]

The windows build seems to be failing because the files in test_site have different SHA sums.

      <link href="https://replace-this-with-your-url.com/site.css?h=8661df0fd2f603ff954e7e04b66d014c90c72305855e5c360bff4813186d122b" rel="stylesheet">
...
thread 'can_cachebust_static_files' panicked at 'assertion failed: file_contains!(public, "index.html",
               "<link href=\"https://replace-this-with-your-url.com/site.css?h=83bd983e8899946ee33d0fde18e82b04d7bca1881d10846c769b486640da3de9\" rel=\"stylesheet\">")', components\site\tests\site.rs:692:5

This seems to be because git converts line endings on Windows.

$ unix2dos test_site/static/site.css && sha256sum test_site/static/site.css
unix2dos: converting file test_site/static/site.css to DOS format...
8661df0fd2f603ff954e7e04b66d014c90c72305855e5c360bff4813186d122b  test_site/static/site.css
``

I'll see if this can be fixed with `.gitattributes` later when I have time.

[dancek]

Thanks for reviewing! Good points, I'll fix these.

[dancek]

I tried to fix the Windows tests by forcing eol=lf in .gitattributes for the relevant files and fixed the issues from review comments.

[Keats]

Thanks!