Page MenuHomePhabricator

[builds-api,envvars-admission] add TOOL_NAME environment variable
Closed, DuplicatePublicFeature

Description

Feature summary (what you would like to be able to do and where):
Have a new environment available for all tools on Toolforge, giving the name of the tool you're in.

Use case(s) (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
I have a tool with an oauth process using non-confidential credentials (hence why they are not in env variables themselves). There are (or will be) two versions of the app on two separate tools, one beta and the other one main. The oauth process involves a callback URL. The domain name in the address is decided by the tool's name, so I need the tool's name to know which configuration and set of credentials to use as part of the build process of my tool.

Benefits (why should this be implemented?):
There is a TOOL_DATA_DIR that provides a path specific to the tool, seemingly ending with the tool's name as last component, provided for all tools on Toolforge.
It would be a good idea to have the tool's name directly accessible, for instance through a TOOL_NAME variable.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

As a workaround you can read /var/run/secrets/kubernetes.io/serviceaccount/namespace and strip off the tool- prefix from inside the pod.

Nope, doesn't work, not at build time. It gets me "image-build". Same issue as T434369.

Nope, doesn't work, not at build time. It gets me "image-build". Same issue as T434369.

Yep, that's because the builds don't happen in the tool namespace, but in image-build

An image is not inherently tried to a tool, as it is possible to build an image with one tool and deploy it to an another. https://wikitech.wikimedia.org/wiki/Tool:Containers is a good example of that sort of a pattern, and the dev tool of openstack-browser currently an another.

Instead, the --envvar flag of toolforge build start seems like a good candidate for this kind of build-time configuration injection. Do we expose that as an option in the component manifest yet?

An image is not inherently tried to a tool, as it is possible to build an image with one tool and deploy it to an another. https://wikitech.wikimedia.org/wiki/Tool:Containers is a good example of that sort of a pattern, and the dev tool of openstack-browser currently an another.

Instead, the --envvar flag of toolforge build start seems like a good candidate for this kind of build-time configuration injection. Do we expose that as an option in the component manifest yet?

Not yet no, should not be too hard to add either, just did not get around to it.

I do think that it's still reasonable to populate the an envvar TOOL_NAME both when building and when running an image. Builds are still done in a tool, not by themselves (this is having the envvar at bulid time, not hardcodding it inside the image, then when running, if it runs in a different tool, it will have a different value).

I do agree though that --envvar might be the safest/clearest option to tweak build time behavior.

dcaro renamed this task from TOOL_NAME environment variable to [builds-api,envvars-admission] add TOOL_NAME environment variable.Aug 11 2026, 9:44 AM