Custom build commands

[LordMZTE]

It would be very useful to have an optional field in the config.toml file like build_command which takes a string which is a shell command that will be executed before the site is generated. This would allow for, for example compiling JS from other languages such as TS, to be used in the page. Additionally, it would also be great to be able to include the output of a custom command in the site. That way, for example a git commit hash could automatically be added to the site.

[Keats]

What's the advantage of having it in config.toml ? How does it interact with zola serve?

[LordMZTE]

What's the advantage of having it in config.toml ? How does it interact with zola serve?

If it would be used for building scripts, then it would be necessary to run it before zola serve in order for the site to work properly.

[heitorPB]

I usually have a Makefile for that. This way I can add as many preprocessing steps as I need. The downside is that if I change only one file, i have to either run make (that will re-preprocess everything), or manually run the scripts on that one file.

[Keats]

Its not going to be built-in Zola.

[LordMZTE]

Its not going to be built-in Zola.

Alright, but what do you recommend for solving this issue? Is there some other way to achieve this with zola, or should an external tool like make be used?

[Keats]

I would use a Makefile yes

[ghost]

Its not going to be built-in Zola.

Not a very developer-friendly response. This should be reopened for consideration. It could be useful for a lot of purposes. For instance, to use a script for generating markdown files from some other format. There are an infinite number of reasons that someone might want to do some preprocessing before build.

[c-git]

Personally one of the main attractions for me with zola is that

1. I can if I want to make any changes I want, it's all open
2. That the project is simple by intention not chance.

I think adding this doesn't add much value over a make file but adds a fair bit of complexity because it raises several questions that do not have obvious answers and that is often an indication that that it's not the right way to go. For example the one posed by the author about what happens to zola serve imo is material. It should have first class support but what does that mean? I think different people will have different expectations and there wouldn't really be a way to please everyone.

Furthermore, I think the differential between just adding a zola build to the end of a script of a make file or adding it into zola doesn't justify making the program more complicated.

[ghost]

I don't think it would have to be too complicated really. All it would have to do is give the user an option to run a command prior to build, and maybe respond to an exit code. If something goes wrong with the user-defined command, then that's the user's problem to deal with.

This is by no means a necessary feature, and I wouldn't be bothered if it wasn't added. It's just a convenient time saver. Since there is no way to tell zola to run a build command, I have to 1) kill the zola server, 2) then run my script manually, 3) then restart zola ... each and every time I make a change. It would be a lot easier to just tell zola to run my command on each rebuild so all of this can happen automatically

Maybe it is more work than I imagine it would be to add a feature like this to zola, but the way I envision it working didn't seem too complicated, and I hated to see the issue closed without any consideration. Custom scripts can give the developer so much more flexibility

[c-git]

I do think it was considered based on the conversation and I do think it's more complicated than you imagine given the little I do know but I could be wrong. However, all my websites that use zola also have a script running and for me there would be no advantage to setting it in zola instead of just adding it to that script so I guess I'm not the target user demographic as well.

[Keats]

Not a very developer-friendly response. This should be reopened for consideration. It could be useful for a lot of purposes.

Yes it can be useful but that doesn't mean it needs to be added. It adds a lot of complexity that will be better handled outside of Zola. For example:

• different commands for build and server
• different commands depending on OS
• commands to run after a build
• filters for events on serve
• caching of commands

And probably more I'm not thinking of right now. You can say we don't need all of those but it's as arbitrary as not allowing anything. I'll take the Makefile.

[heitorPB]

Here's a sample Makefile to help you get started:

.PHONY: preprocess
preprocess: ## Preprocess content before building/serving
        @echo "Preprocessing step".
        @echo ./script.sh

.PHONY: build
build: preprocess ## Build website
        @zola build

.PHONY: serve
serve: preprocess ## Serve the website
        @zola serve

.PHONY: help
help: ## Displays this help
        @grep -E '^[a-zA-Z_-]+:.*?## .*$$' $(MAKEFILE_LIST) | awk 'BEGIN {FS = ":.*?## "}; {printf "\033[36m%-20s\033[0m %s\n", $$1, $$2}'

Typing make or make preprocess will run your preprocessing step. And make build/make serve runs the preprocessing and then build/serve the website.

I use something similar to this for my local development. I have a terminal running make serve and when I make changes in the content I just make preprocess and Zola serves the updated content.

[mo8it]

it would also be great to be able to include the output of a custom command in the site.

@LordMZTE I built the CLI http-cmd for exactly this use case: https://codeberg.org/mo8it/http-cmd

It can be used to run a command and embed its output in the built HTML. The repository contains Zola examples.

One could try to also use it to basically run a command on each build without using the output, but I didn't try it yet. Zola caches fetched remote data using load_data based on the URL. If you attach get_random to the URL, that might be enough to invalidate the cache on each build.