Footer commit hash is incorrectly generated by the hugo --gc=true --minifystep in .drone.yml.
The image above displays a hash linking to a commit, which is no longer relevant as the latest that modified the subject page.
It's a template code-generated hash so any page using it is affected.
As each build is run in a separate container using Drone, I'd start by removing the garbage collector thing (--gc=true) 🙈
Footer commit hash is incorrectly generated by the `hugo --gc=true --minify` [step](https://git.dotya.ml/dotya.ml/homepage/src/commit/ee547ad4c4b3aa32057bc425a46e48d98c2d6f0c/.drone.yml#L43) in [.drone.yml](https://git.dotya.ml/dotya.ml/homepage/src/commit/ee547ad4c4b3aa32057bc425a46e48d98c2d6f0c/.drone.yml).
The image above displays a hash linking to a [commit](https://git.dotya.ml/dotya.ml/homepage/commit/ef33e6a44943b112180dfa2f30ef0f6735c4768e), which is no longer relevant as the latest that modified the subject page.
It's a template code-generated hash so any page using it is affected.
As each build is run in a separate container using Drone, I'd start by removing the garbage collector thing (`--gc=true`) 🙈
Example of a correct (as of now) [hash](https://git.dotya.ml/dotya.ml/homepage/commit/d80c31f3ca83fa0a051e064344f7edc901cbd121)
this might actually be a hugo bug.
running hugo multiple times in a row outputs correct hash inconsistently to the public/ folder files (which it should do either never or always)
this might actually be a `hugo` bug.
running `hugo` multiple times in a row outputs correct hash inconsistently to the `public/` folder files (which it should do either never or always)
this issue was only observable on non-posts (such as the about and contact pages), a post page shows the hash just fine so it is safe to assume the issue is not with Hugo but our usage of the hash outside of posts.
ref: https://dotya.ml/posts/dnscrypt/
this issue was only observable on non-posts (such as the about and contact pages), a post page shows the hash just fine so it is safe to assume the issue is not with Hugo but our usage of the hash outside of posts.
ref: https://dotya.ml/posts/dnscrypt/
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Footer commit hash is incorrectly generated by the
hugo --gc=true --minifystep in .drone.yml.The image above displays a hash linking to a commit, which is no longer relevant as the latest that modified the subject page.
It's a template code-generated hash so any page using it is affected.
As each build is run in a separate container using Drone, I'd start by removing the garbage collector thing (
--gc=true) 🙈Example of a correct (as of now) hash
this might actually be a
hugobug.running
hugomultiple times in a row outputs correct hash inconsistently to thepublic/folder files (which it should do either never or always)this issue was only observable on non-posts (such as the about and contact pages), a post page shows the hash just fine so it is safe to assume the issue is not with Hugo but our usage of the hash outside of posts.
ref: https://dotya.ml/posts/dnscrypt/