crohr / pkgr

Package any app into deb or rpm packages, using heroku buildpacks
http://crohr.me/pkgr/
MIT License
591 stars 66 forks source link

Running behind proxy fails to build package #141

Closed obfuscoder closed 6 years ago

obfuscoder commented 6 years ago

Our build environment is only able to access the internet via proxies.

The environment variables http_proxy, htts_proxy and no_proxy are defined so that curl, bundler and wget can access the internet as needed.

However, building the debian package with pkgr package fails at the following step:

-----> Compiling Ruby/Rails
-----> Using Ruby version: ruby-2.3.4
-----> Installing dependencies using bundler 1.16.0
       Running: bundle install --without development:test --path vendor/bundle --binstubs vendor/bundle/bin -j4 --deployment
       Warning: the running version of Bundler is older than the version that created the lockfile. We suggest you upgrade to the latest version of Bundler by running `gem install bundler`.
       Fetching source index from https://rubygems.org/
       Retrying fetcher due to error (2/4): Bundler::HTTPError Could not fetch specs from https://rubygems.org/
       ....

Ater 4 retries the process aborts.

When enabling the --debug option I can see the following output when triggering the heroku-ruby-buildpack:

...
DEBUG: Running "env -i PATH=\"$PATH\" TARGET=debian:8 BUILDPACK_NODE_VERSION=\"0.6.8\" /home/user/.pkgr/buildpacks/builtin/7f03e5472376de1229ddab91b5cb7b0b9c1f3e33/heroku-buildpack-ruby/bin/compile \"/tmp/d20180129-21812-q3gnct/opt/project\" \"/tmp/d20180129-21812-q3gnct/opt/project/.git/cache\" \"/tmp/d20180129-21812-10zp41w\" "

My assumption is that pkgr initiates the buildpack without transfering the environment from the current process to the buildpack. To verify my assumption, I tried to inject some debugging output into a fork of the buildpack used by pkgr for ruby projects, but encountered some problems.

obfuscoder commented 6 years ago

There is the parameter --env which allows me to et addition env variables when calling buildpack. Is there a specific reason for using a clean env when calling buildpack?

crohr commented 6 years ago

Yes, pkgr uses a clean env to avoid any pollution from the current environment, typically to avoid any existing ruby version on the system to be picked up while running the buildpack.

You should indeed use the --env flag to pass any env variables that need to be used by the subprocesses.