Move versioning into a docker pre-build step, and out of lemmy.

[dessalines]

This moves versioning out of the lemmy codebase, and into the docker build, by overwriting a version.rs file based on the CI_PIPELINE_EVENT from woodpecker.

Was also able to get rid of the git_version dependency in lemmy.

I canceled the below tagged builds, but the links show that the version.rs file is being written correctly.

• Tagged version
• cron / Nightly version

Matching lemmy-ui PR

[Nutomic]

Instead of a file I would use an environment variable. That way its not necessary to make any changes to the source code, and will be easier for external people who want to package Lemmy without being familiar with the code. If the environment variable is set it should use that, and otherwise fallback to git-version.

This should also be mentioned in the install from scratch documentation.

[dessalines]

Hrm. I think in this case a version file is much better than an env var, because this should be a compile (or really a pre-compile since the version should be filled before that) time step, not a changeable run-time variable. If we wanted it to be changeable, I'd recommend putting it in the lemmy.hjson anyway (then at least it would only be read once), but that really doesn't make sense here, because we don't want ppl injecting random lemmy version strings which might be wrong.

Plus with using an env var, it'd have to get read every time, which doesn't make sense for something that's never going to change.

If people are building custom lemmy versions, I can def update those from scratch instructions to point to this version file, so that they can write their own.

The code changes here are also good because they solve a lot of weird re-compiling issues we're getting from lemmy's runtime trying to read the git version.

[Nutomic]

Of course I meant a compile time env var using option_env, sorry if that wasnt clear. This way its not necessary to know any file path or include Rust/TS specific code. If the env var is not set it should still fallback git-version, even though we are not using that in our own builds. Its mainly useful for instances that are running their own forks with extra changes. In debug mode it should simply use the version from Cargo.toml like before.

[dessalines]

I suppose I'd be fine with an env var (although I really don't think its as explicit and clear as a version file), but I really don't think lemmy should be doing any internal logic trying to figure out which git tag or commit it is (and I also don't think using the version from Cargo.toml is a great idea, since there may be modifications). This should all be outside of lemmy, and all it should be doing is reading a file or env var.

Otherwise we will run into recompile issues again, since git is always changing.

For people running custom lemmy's, with the current file version, all we have to do is tell people to edit crates/utils/src/version.rs with their version name, before doing a release. That's extremely simple.

[dessalines]

Also the release.bash script could just also edit this too, to the current version. Then anyone running non-custom lemmys from scratch would be fine.

[dessalines]

EDIT: this is done now.

[dessalines]

I tried messing around with an env version, but it ended up being much worse and more verbose, due to this docker bug of not being able to easily set an env var from the result of a command: https://stackoverflow.com/questions/34911622/dockerfile-set-env-to-result-of-command

You basically have to write a file no matter what if you want to persist the result of any command in docker.