Environment Specification

Components use several channels to exchange information with Keboola Connection, primarily structured folders and configuration files. Each component has full access to the outside network (network type bridge), unless changed to none in Developer portal. Additional parts of the environment in which your component is executed are specified below.

Environment Variables

The following environment variables are injected in the container:

  • KBC_DATADIR: This is always /data/ in KBC; use this environment variable during component development to create development and testing environments.
  • KBC_RUNID: RunId from Storage; it couples all events within an API call (use this for logging)
  • KBC_PROJECTID: Id of the project in KBC within a KBC stack.
  • KBC_STACKID: Id of the KBC stack.
  • KBC_CONFIGID: Id of the configuration or hash of configuration data if the configuration is not named (configData was used in API call).
  • KBC_COMPONENTID: Id of the component

The following variables are available only if “Forwards token” and “Forwards token details” are enabled in component configuration (and approved by us):

  • KBC_PROJECTNAME: Name of the project in KBC.
  • KBC_TOKENID: Id of the token running the container.
  • KBC_TOKENDESC: Description (user name or token name) of the token running the container.
  • KBC_TOKEN: The actual token running the container.
  • KBC_URL: The Storage API URL.

The following variables are available when GELF Logger is enabled in the component configuration:

  • KBC_LOGGER_ADDR: IP address of GELF server
  • KBC_LOGGER_PORT: Port of the GELF server

Return Values

The script defined in Dockerfile ENTRYPOINT or CMD should provide an exit status. The following rules apply:

  • exit code = 0 The execution is considered successful.
  • exit code = 1 The execution fails with a User Error; the contents of both STDOUT and STDERR will be sent to Storage API Events.
  • exit code > 1 The execution fails with an Application Error and the contents of both STDOUT and STDERR will be sent to internal logs.

It is possible to modify the above behavior so that regardless of the exit code, all errors are User Errors. This is done by setting no_application_errors in component configuration. See the implementation notes for tips on distinguishing between a User Error and Application Error.