Use git hash to break cache

[SleeplessOne1917]

Closes #1676

[alectrocute]

Pending @sunaurus’s feedback and the missing new line at the end of one of those files, this looks great and solves a huge bug. Fantastic!

[alectrocute]

Also, epic rhyme in PR title.

[alectrocute]

What’s going on with CI here? Definitely would be great to get this in the next RC.

[sunaurus]

Suggested change

	publicPath: `/static/${commitHash}`
	publicPath: `/static/${commitHash}/`

Without the trailing slash the paths break:

Unhandled Promise Rejection: ChunkLoadError: Loading chunk 76292 failed.
(error: http://localhost:1234/static/3caf913614868f70475430fca3dcc40c61d613b5js/76292.client.js)

[sunaurus]

This is totally optional, but IMO using the --short git hashes will be a bit nicer while still giving absurdly low chances of collisions.

With git rev-parse HEAD: http://localhost:1234/static/3caf913614868f70475430fca3dcc40c61d613b5/js/76292.client.js

With git rev-parse --short HEAD: http://localhost:1234/static/3caf913/js/76292.client.js

[alectrocute]

Sorry to complicate things, but couldn't we just do cache busting without git, eg. webpack config?

[sunaurus]

I think the issue with webpack hashes is that we run the server and client webpack builds seperately, and I'm not sure if there's any clean way to take the resulting hash(es) from the client build, and replace them into imports in the generated server files. My assumption is that it would require a bigger refactor of the webpack configuration. But I'm no webpack expert, maybe there's some obvious way to do it that I'm missing!

[alectrocute]

I think the issue with webpack hashes is that we run the server and client webpack builds seperately, and I'm not sure if there's any clean way to take the resulting hash(es) from the client build, and replace them into imports in the generated server files. My assumption is that it would require a bigger refactor of the webpack configuration. But I'm no webpack expert, maybe there's some obvious way to do it that I'm missing!

I think there's a way to export the contenthash that webpack generates and export it as an env variable to be used by the server, but I'm also not an expert in webpack. :/

[dessalines]

@SleeplessOne1917 @sunaurus Ya that's an easy one to fix:

In the .woodpecker.yml, add this before the yarn build:dev

- apk add git

[dessalines]

Okay actually I'm kinda changing my mind a bit:

Check out this line: https://github.com/LemmyNet/lemmy-ui/blob/main/Dockerfile#L27

It should also set the commit hash there.

Why not just let the webpack read the version / commit hash from the version.ts file? The UI, the build, everything reads from that version.ts file as the source of truth.

[SleeplessOne1917]

I think the issue with webpack hashes is that we run the server and client webpack builds seperately, and I'm not sure if there's any clean way to take the resulting hash(es) from the client build, and replace them into imports in the generated server files. My assumption is that it would require a bigger refactor of the webpack configuration. But I'm no webpack expert, maybe there's some obvious way to do it that I'm missing!

Pretty much this. The built in hashes for webpack were the first thing I tried, but I couldn't figure out how to use them in the actual code.

@dessalines

Check out this line: https://github.com/LemmyNet/lemmy-ui/blob/main/Dockerfile#L27
It should also set the commit hash there.

See the most recent commit I made. Using the hash is now docker agnostic, and it's set as an environment variable.

[dessalines]

Can you make this into a bundleFolder() or bundleDir() function? That way we won't have to trace all these down again potentially in the future.

[alectrocute]

+1. I vote for something like getStaticDir and have it in @utils/env.

[SleeplessOne1917]

I'll make the change during my lunch break.

[alectrocute]

Made the changes.