Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vendor buildpack-stdlib instead of fetching from S3 #1100

Merged
merged 1 commit into from
Oct 19, 2020

Conversation

edmorley
Copy link
Member

@edmorley edmorley commented Oct 15, 2020

Since fetching buildpack-stdlib from S3 has a number of disadvantages:

  • it's not possible to grep the repo when trying to work out what something from the stdlib is doing (for example when debugging Expose BPLOG_PREFIX to sub-shells again #1099)
  • shellcheck can't fully scan the code, since it similarly doesn't have the source
  • it's another compile-time HTTP request that can fail due to transient network issues and so reduce reliability
  • adds a dependency on the security/release-process of an additional S3 bucket

Since the stdlib is small, doesn't often change, and is not a binary, it's a great fit for just vendoring in the repo.

The BIN_DIR calculation added to bin/utils is based on the approach mentioned here:
https://www.ostricher.com/2014/10/the-right-way-to-get-the-directory-of-a-bash-script/

...rather than copying the version in bin/compile, since the latter uses $0 so doesn't work with sourced scripts (such as bin/utils).

Closes W-8094463.

@edmorley edmorley self-assigned this Oct 15, 2020
Since fetching from S3 has a number of disadvantages:
- it's not possible to grep the repo when trying to work out what
  something from the stdlib is doing
- shellcheck can't fully scan the code, since it similarly doesn't
  have the source
- another compile-time HTTP request that can fail due to transient
  network issues and so reduce reliability
- dependency on the security/release-process of an additional bucket

Since the stdlib is small, doesn't often change, and is not a binary,
it's a great fit for just vendoring in the repo.

Closes W-8094463.
@edmorley edmorley force-pushed the vendor-buildpack-stdlib branch from e326a84 to 63c001a Compare October 15, 2020 17:19
@edmorley edmorley marked this pull request as ready for review October 15, 2020 17:44
@edmorley edmorley requested a review from a team as a code owner October 15, 2020 17:44
@edmorley edmorley merged commit 9b1a69a into main Oct 19, 2020
@edmorley edmorley deleted the vendor-buildpack-stdlib branch October 19, 2020 11:27
edmorley added a commit that referenced this pull request Oct 19, 2020
The changelog entries for #1099 and #1100 were added to the previous
release section (rather than the "unreleased" section) by mistake.
edmorley added a commit that referenced this pull request Oct 19, 2020
The changelog entries for #1099 and #1100 were added to the previous
release section (rather than the "unreleased" section) by mistake.
dryan pushed a commit to dryan/heroku-buildpack-python that referenced this pull request Nov 19, 2020
Since fetching buildpack-stdlib from S3 has a number of disadvantages:
- it's not possible to grep the repo when trying to work out what
  something from the stdlib is doing
- shellcheck can't fully scan the code, since it similarly doesn't
  have the source
- another compile-time HTTP request that can fail due to transient
  network issues and so reduce reliability
- dependency on the security/release-process of an additional bucket

Since the stdlib is small, doesn't often change, and is not a binary,
it's a great fit for just vendoring in the repo.

The `BIN_DIR` calculation added to `bin/utils` is based on the approach
mentioned here:
https://www.ostricher.com/2014/10/the-right-way-to-get-the-directory-of-a-bash-script/

...rather than copying the version in `bin/compile`, since the latter uses
`$0` so doesn't work with sourced scripts (such as `bin/utils`).

Closes W-8094463.
dryan pushed a commit to dryan/heroku-buildpack-python that referenced this pull request Nov 19, 2020
The changelog entries for heroku#1099 and heroku#1100 were added to the previous
release section (rather than the "unreleased" section) by mistake.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants