Documentation
¶
Index ¶
Constants ¶
const DefaultEnvfilePathEnv = "BITRISEIO_ENVFILE_PATH"
DefaultEnvfilePathEnv is the env var that points to the (platform-dependent) envfile location.
Variables ¶
This section is empty.
Functions ¶
func GetEnv ¶
func GetEnv(key string, runtimeEnvs envmanModels.EnvsJSONListModel, envfilePath string) (string, error)
GetEnv returns the true value of an env var, even if its value was erased because of its size. Typical large env vars are git-related build trigger env vars, like BITRISE_GIT_COMMIT_MESSAGES or BITRISE_GIT_CHANGED_FILES. If these were exposed as env vars to the CLI process, the execve() syscall would fail because it has a limit on the size of all env vars and arguments. Instead, the agent launching the Bitrise CLI process clears these env vars and stores their original values in a file on disk. Why is this whole thing not implemented with envman? Because a step subprocess is started with all env vars (prepared by envman), so that subprocess exec would also fail with the same error when passing large env vars. Note: envfilePath must point to an existing file, you should not call this unconditionally.
func LogEnvVarLimitIfExceeded ¶
func LogEnvVarLimitIfExceeded()
Source Files