fix: don't override WEB_CONCURRENCY if set

[dirkkelly]

No description provided.

[dirkkelly]

@jordanmaguire wanted to get the existance of these repos in front of your eyes, we will be discussing more next week https://3.basecamp.com/3601722/buckets/1937663/todos/3862709740

[jordanmaguire]

@dirkkelly This seems like a bug in the buildpack to me - are we intending to create a PR back into the source?

[dirkkelly]

@jordanmaguire yeah agreed it seems like a bug in the heroku buildpack, going to create a PR if we're happy with the change on our side.

[jordanmaguire]

This change is fine.

I have some higher level questions around things like:

• How is the version of our buildpacks usually managed
• How will this need to change by running our own version of a buildpack. How will we be pulling the master of the source of this repo into this one so we can continue to receive changes

[dirkkelly]

@jordanmaguire usually we just use the heroku/nodejs default, eg:

$ heroku buildpacks -a app

=== app Buildpack URLs
1. heroku/nodejs
2. heroku/ruby

On the branch within our system where we're testing this alternative buildpack that has been changed to point to this branch.

$ heroku buildpacks -a app-pr-123

=== app-pr-123 Buildpack URLs
1. https://github.com/interexchange/heroku-buildpack-nodejs.git#fix-web-concurrency
2. heroku/ruby

We can make the decision to wait to update our environments until this is merged or temporarily use our branch / repo while we wait for the heroku official to update (which would require keeping up-to-date with upstream).

I think best next step is to create a PR on the Heroku repo and see what the maintainers have to say.

[dirkkelly]

Created a PR on Heroku's upstream heroku#926