Hugo-generated footer modification commit hash incorrect #9

New Issue

wanderer · 2020-09-09T00:48:47+02:00

wanderer commented

2020-09-09 00:48:47 +02:00

Footer commit hash is incorrectly generated by the hugo --gc=true --minify step 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

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). ![image](/attachments/b260100b-af7c-44ab-9c85-4383ec10eb9e) 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) ![image](/attachments/f4c8a33d-fa4b-4c82-b21e-af4e90a7786c)

image.png

13 KiB

image.png

12 KiB

wanderer added the

bug

label 2020-09-09 00:48:47 +02:00

wanderer self-assigned this 2020-09-09 00:48:47 +02:00

wanderer added this to the General project 2020-09-09 00:58:17 +02:00

wanderer commented

2020-09-13 21:04:52 +02:00

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)

wanderer commented

2021-08-08 01:03:17 +02:00

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/ ![image](/attachments/724db37c-85d2-4e96-b950-e3173bd6ee6b)

image.png

54 KiB

wanderer closed this issue

2021-08-08 01:04:07 +02:00

Sign in to join this conversation.