Node chaincode, Java chaincode and possibly Go chaincode have a need to connect to remote repositories. That connection or destination may have to be configured explicitly. For example a proxy has to be defined or for node you want to use alternative repositories to the standard ones used by the chaincode container builders.
These configuration values could be passed somehow within the chaincode package, for example, node, you can include a .npmrc file to provide these configuration values, however these values may be specific to a single org meaning another org would have to have a slightly different chaincode package which would be a problem. But it might not be possible for other languages. And then you have to set it on all chaincode packages as well.
It should be possible to provide specific environment variables and their values which can be inherited by the chaincode builder container from the peer to provide appropriate configuration for a specific environment. We don't want to pass all the peers env vars to the chaincode container so it should be a restricted set. I don't think we should hard code that set as this would be too inflexible. A couple of suggestions (but welcome other suggestions)
A single env var that contains a list of env vars and their values
The env vars are prefixed with something like BUILDER_. Any env var with the prefix would be passed to the chaincode container without the prefix.
Node chaincode, Java chaincode and possibly Go chaincode have a need to connect to remote repositories. That connection or destination may have to be configured explicitly. For example a proxy has to be defined or for node you want to use alternative repositories to the standard ones used by the chaincode container builders.
These configuration values could be passed somehow within the chaincode package, for example, node, you can include a .npmrc file to provide these configuration values, however these values may be specific to a single org meaning another org would have to have a slightly different chaincode package which would be a problem. But it might not be possible for other languages. And then you have to set it on all chaincode packages as well.
It should be possible to provide specific environment variables and their values which can be inherited by the chaincode builder container from the peer to provide appropriate configuration for a specific environment. We don't want to pass all the peers env vars to the chaincode container so it should be a restricted set. I don't think we should hard code that set as this would be too inflexible. A couple of suggestions (but welcome other suggestions)
BUILDER_. Any env var with the prefix would be passed to the chaincode container without the prefix.