As it says here, under "Globally set environment variables", that variable should exist, and contain a path whose last component is the name of the tool.

Those docs are specific for runtime, it should be more clear yep.

Could be useful to expose them at build time though, might be a bit trickier though (as the builds happen in the shared image-build namespace, not the tool namespace).

Oh. Hadn't thought of that nuance. Well yes, in the case of static websites you need this kind of thing at build time, not at run time.

Though, before introducing a revolution in how image building works, the only thing I need is some way to get the name of my own tool (from JS ran by Node) at build time, nothing more.

In T434369#12200143, @Gouvernathor wrote:

Oh. Hadn't thought of that nuance. Well yes, in the case of static websites you need this kind of thing at build time, not at run time.

TOOL_DATA_DIR is a container runtime thing because it is really about finding the NFS mount for data that persists across container restarts. The toolforge build start workflow is a container image build process that is 100% disconnected from the optional runtime NFS mounts (for example added by --mount all with toolforge jobs run).

In T434369#12200214, @Gouvernathor wrote:

Though, before introducing a revolution in how image building works, the only thing I need is some way to get the name of my own tool (from JS ran by Node) at build time, nothing more.

One hack you could use for that right now is injecting an envvar with --envvar TOOL_DATA_DIR=... or something more specific like toolforge build start --envvar TOOL_NAME=$(id -un|cut -d. -f2) ....

T419601: [envars] Provide a $TOOL or $TOOL_NAME default envvar is a separate feature request for a runtime variable with the tool's name.

I understand the distinction you're making, and I'll take your id workaround which will probably be good enough for me.
I'll note however that considering that only the run time, and not the build time, would benefit from these kind of useful information (the reason such env variables are included is because it is useful), is mistaken in my view, because for static apps, if something can change depending on the tool or whatever else, the switch occurs at build time and not at run time.

In T434369#12219331, @Gouvernathor wrote:

I'll note however that considering that only the run time, and not the build time, would benefit from these kind of useful information (the reason such env variables are included is because it is useful), is mistaken in my view, because for static apps, if something can change depending on the tool or whatever else, the switch occurs at build time and not at run time.

I mentioned T419601 here because it is obviously related to the hack I presented to unblock you.

I think it would be great for both TOOL_DATA_DIR and the proposed TOOL_NAME variable to be available in both build and runtime environments.

I think it would be great for both TOOL_DATA_DIR and the proposed TOOL_NAME variable to be available in both build and runtime environments.

I agree there are use cases for this, but it is a little bit of a strange case in the way the build system currently works - images are not explicitly tied to tools, though they are implicitly related as the tool authenticates and the registry prefix is that of the tool.

If this is implemented it should be very clear the values are dynamic and build vs runtime can be different - I have several images which are run cross-user (to avoid building the same image dozens of times).

My solution to this currently is to have an entrypoint script which looks up the namespace (via /var/run/secrets/kubernetes.io/serviceaccount/namespace) and deduces the tool name from that, then writes the config; having the tool_name in runtime would be a cleaner way to do that, but I wouldn't switch to doing it during build time.