-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Open
Labels
bugSomething isn't workingSomething isn't working
Description
Current Behavior
Description:
When reading environment variables in the init_by_lua phase, if two variables share a common prefix (e.g., KUBERNETES_CLIENT_TOKEN and KUBERNETES_CLIENT_TOKEN_FILE), the value of the shorter-named variable may be erroneously returned when the longer-named one is requested. The issue appears to be sensitive to the order in which the variables are defined in the configuration.
Expected Behavior
Expected behavior:
os.getenv("KUBERNETES_CLIENT_TOKEN_FILE") should always return the value of the environment variable named exactly KUBERNETES_CLIENT_TOKEN_FILE, regardless of the definition order of the env directives.
Error Logs
No response
Steps to Reproduce
Steps to reproduce:
- Create a test configuration similar to
t/kubernetes/discovery/kubernetes2.tthat defines two environment variables with a common prefix, e.g.:env KUBERNETES_CLIENT_TOKEN=some-token; env KUBERNETES_CLIENT_TOKEN_FILE=/path/to/token; - In
init_by_lua, attempt to readKUBERNETES_CLIENT_TOKEN_FILEusingos.getenv("KUBERNETES_CLIENT_TOKEN_FILE"). - Observe that the returned value is
some-token(the value of the shorter variable) instead of/path/to/token. - Swap the order of the two
envdirectives so that the longer name (KUBERNETES_CLIENT_TOKEN_FILE) appears first:env KUBERNETES_CLIENT_TOKEN_FILE=/path/to/token; env KUBERNETES_CLIENT_TOKEN=some-token; - In
init_by_lua, again readKUBERNETES_CLIENT_TOKEN_FILE– this time it returns the correct value/path/to/token.
Environment
master branch
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
bugSomething isn't workingSomething isn't working
Type
Projects
Status
📋 Backlog