-
Notifications
You must be signed in to change notification settings - Fork 112
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
Don't allow post_read directives on location context #217
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mruby_post_read_handler
not running in 1.18.3+mruby_post_read_handler
not running in 1.18.3+
077b918
to
9b3114e
Compare
9b3114e
to
67403f3
Compare
f81c4c4
to
34eae2a
Compare
mruby_post_read_handler
not running in 1.18.3+
edmorley
added a commit
to heroku/heroku-buildpack-static
that referenced
this pull request
Nov 7, 2020
The `mruby_post_read_handler` directive should always have been outside the `location` block, however due to a bug in ngx_mruby the previous implementation happened to still work. In ngx_mruby 1.18.4 this silently stopped being the case: matsumotory/ngx_mruby#210 And in ngx_mruby 1.18.5 this incorrect usage was turned into an error: matsumotory/ngx_mruby#217 Moving `mruby_post_read_handler` outside the location block is a no-op for the older ngx_mruby currently used by this buildpack, but ensures compatibility with the newer ngx_mruby being used in the upcoming Heroku-20 support PR. See matsumotory/ngx_mruby#210.
edmorley
added a commit
to heroku/heroku-buildpack-static
that referenced
this pull request
Nov 7, 2020
The `mruby_post_read_handler` directive should always have been outside the `location` block, however due to a bug in ngx_mruby the previous implementation happened to still work. In ngx_mruby 1.18.4 this silently stopped being the case: matsumotory/ngx_mruby#210 And in ngx_mruby 1.18.5 this incorrect usage was turned into an error: matsumotory/ngx_mruby#217 Moving `mruby_post_read_handler` outside the location block is a no-op for the older ngx_mruby currently used by this buildpack, but ensures compatibility with the newer ngx_mruby being used in the upcoming Heroku-20 support PR. See matsumotory/ngx_mruby#210.
edmorley
added a commit
to heroku/heroku-buildpack-static
that referenced
this pull request
Nov 7, 2020
The `mruby_post_read_handler` directive should always have been outside the `location` block, however due to a bug in ngx_mruby the previous implementation happened to still work. In ngx_mruby 1.18.4 this silently stopped being the case: matsumotory/ngx_mruby#210 And in ngx_mruby 1.18.5 this incorrect usage was turned into an error: matsumotory/ngx_mruby#217 Moving `mruby_post_read_handler` outside the location block is a no-op for the older ngx_mruby currently used by this buildpack, but ensures compatibility with the newer ngx_mruby being used in the upcoming Heroku-20 support PR. See matsumotory/ngx_mruby#210.
edmorley
added a commit
to heroku/heroku-buildpack-static
that referenced
this pull request
Nov 9, 2020
The `mruby_post_read_handler` directive should always have been outside the `location` block, however due to a bug in ngx_mruby the previous implementation happened to still work. In ngx_mruby 1.18.4 this silently stopped being the case: matsumotory/ngx_mruby#210 And in ngx_mruby 1.18.5 this incorrect usage was turned into an error: matsumotory/ngx_mruby#217 Moving `mruby_post_read_handler` outside the location block is a no-op for the older ngx_mruby currently used by this buildpack, but ensures compatibility with the newer ngx_mruby being used in the upcoming Heroku-20 support PR. See matsumotory/ngx_mruby#210.
edmorley
added a commit
to heroku/heroku-buildpack-static
that referenced
this pull request
Nov 9, 2020
The `mruby_post_read_handler` directive should always have been outside the `location` block, however due to a bug in ngx_mruby the previous implementation happened to still work. In ngx_mruby 1.18.4 this silently stopped being the case: matsumotory/ngx_mruby#210 And in ngx_mruby 1.18.5 this incorrect usage was turned into an error: matsumotory/ngx_mruby#217 Moving `mruby_post_read_handler` outside the location block is a no-op for the older ngx_mruby currently used by this buildpack, but ensures compatibility with the newer ngx_mruby being used in the upcoming Heroku-20 support PR. See matsumotory/ngx_mruby#210.
mikaelbartlett
pushed a commit
to nixonnixon/heroku-buildpack-static
that referenced
this pull request
Apr 4, 2021
The `mruby_post_read_handler` directive should always have been outside the `location` block, however due to a bug in ngx_mruby the previous implementation happened to still work. In ngx_mruby 1.18.4 this silently stopped being the case: matsumotory/ngx_mruby#210 And in ngx_mruby 1.18.5 this incorrect usage was turned into an error: matsumotory/ngx_mruby#217 Moving `mruby_post_read_handler` outside the location block is a no-op for the older ngx_mruby currently used by this buildpack, but ensures compatibility with the newer ngx_mruby being used in the upcoming Heroku-20 support PR. See matsumotory/ngx_mruby#210.
sidmitra
pushed a commit
to Airbase/heroku-buildpack-static
that referenced
this pull request
Jun 21, 2021
The `mruby_post_read_handler` directive should always have been outside the `location` block, however due to a bug in ngx_mruby the previous implementation happened to still work. In ngx_mruby 1.18.4 this silently stopped being the case: matsumotory/ngx_mruby#210 And in ngx_mruby 1.18.5 this incorrect usage was turned into an error: matsumotory/ngx_mruby#217 Moving `mruby_post_read_handler` outside the location block is a no-op for the older ngx_mruby currently used by this buildpack, but ensures compatibility with the newer ngx_mruby being used in the upcoming Heroku-20 support PR. See matsumotory/ngx_mruby#210.
niels-van-den-broeck
added a commit
to Pelckmans/heroku-buildpack-static
that referenced
this pull request
Dec 22, 2022
* [changelog skip] Ensure PRs include a Changelog entry The goal of this PR is to add a github action that checks for the presence of a changelog entry. It is better to add entries as a PR is merged instead of having to remember what was merged and generate a changelog at release time. By automating this check, it's one less thing the maintainer has to remember, and it's one less thing a change might be blocked on i.e. "Looks good, but please add a changelog entry". Let me know if you have any questions and Happy Friday! * [changelog skip] Fix Escaping in Changelog Script The previous PR had a bug where the REGEX for grep was not properly escaped. This PR fixes that issue. * Update check_changelog.yml * Add missing changelog entries for v4 (heroku#176) And clean up the existing changelog slightly. Closes heroku#175. * Bump json from 2.0.2 to 2.3.1 (heroku#173) Bumps [json](https://github.com/flori/json) from 2.0.2 to 2.3.1. - [Release notes](https://github.com/flori/json/releases) - [Changelog](https://github.com/flori/json/blob/master/CHANGES.md) - [Commits](flori/json@v2.0.2...v2.3.1) Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * Bump rake from 10.4.0 to 12.3.3 (heroku#158) Bumps [rake](https://github.com/ruby/rake) from 10.4.0 to 12.3.3. - [Release notes](https://github.com/ruby/rake/releases) - [Changelog](https://github.com/ruby/rake/blob/master/History.rdoc) - [Commits](ruby/rake@v10.4.0...v12.3.3) Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * Bump excon from 0.54.0 to 0.78.0 (heroku#180) Bumps [excon](https://github.com/excon/excon) from 0.54.0 to 0.78.0. - [Release notes](https://github.com/excon/excon/releases) - [Changelog](https://github.com/excon/excon/blob/master/changelog.txt) - [Commits](excon/excon@v0.54.0...v0.78.0) Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * Bump rack from 1.6.11 to 1.6.13 in /spec/support/docker/proxy (heroku#179) Bumps [rack](https://github.com/rack/rack) from 1.6.11 to 1.6.13. - [Release notes](https://github.com/rack/rack/releases) - [Changelog](https://github.com/rack/rack/blob/master/CHANGELOG.md) - [Commits](rack/rack@1.6.11...1.6.13) Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * Added MIT License (heroku#117) * Remove redundant `exit 0` Since with exit on error, if that line is ever reached, the exit code will always be zero anyway. * Fail the build early on unsupported stacks In order to prevent the build completing apparently successfully, but the app fail to boot at runtime due to stack incompatibility. At first glance this would seem unnecessary due to the stack-specific URL meaning the `curl` would 404 on supported stacks. However heroku#165 means the Cedar-14 binary is installed on all stacks, and on Heroku-20 causes the failures at runtime seen in heroku#166. Future PRs will fix the curl/binary handling to use stack-specific URLs, however it's still nicer to explicitly handle unsupported stacks with a clear error message than a 404. * Remove unused archive caching The caching of the nginx archive isn't used in production (nothing ever writes to the cached file) or in CI. Whilst it may speed up some local development workflows slightly, on a fast connection downloading from S3 takes less than a second, so isn't worth the added `bin/compile` complexity / confusion as to behaviour in production. * Switch to recommended S3 URL format - The `s3-external-1` endpoint is a legacy reference to `us-east-1`: https://stackoverflow.com/a/26622229 - The path based bucket specification is deprecated: https://aws.amazon.com/blogs/aws/amazon-s3-path-deprecation-plan-the-rest-of-the-story/ * Fix the printing of the installed nginx version Previously the nginx version command was failing since the `nginx-$STACK` binary does not exist, resulting in output like: ``` remote: -----> Installed directory to /app/bin ``` This failure went unnoticed since `pipefail` mode is not enabled. The nginx binary path has been fixed, and the command now uses `-v` instead of `-V` since the former only output one line, avoiding the need to `head -n1`. In addition, the `cut` usage shows more of the original line in the case of no match. Fixes heroku#174. * Enable stricter bash error checking modes Enables the following bash modes: - `u`: error on undefined variables - `pipefail`: error if an earlier command in a pipe sequence exits non-zero, rather than only if the final command is non-zero See: http://redsymbol.net/articles/unofficial-bash-strict-mode/ * Make curl retry in case of a failed download To improve the reliability of the build. See: https://curl.haxx.se/docs/manpage.html#--retry https://curl.haxx.se/docs/manpage.html#--connect-timeout * Exclude unnecessary files when publishing buildpack (heroku#178) Since currently the archive on the buildpack registry contains a lot more than the ~15 files needed at compile time: ``` $ curl -sSf https://buildpack-registry.s3.amazonaws.com/buildpacks/heroku-community/static.tgz | tar -zt | wc -l 234 ``` See: https://devcenter.heroku.com/articles/buildpack-registry#creating-a-buildpack-descriptor * Fix compatibility with ngx_mruby 1.18.4+ (heroku#181) The `mruby_post_read_handler` directive should always have been outside the `location` block, however due to a bug in ngx_mruby the previous implementation happened to still work. In ngx_mruby 1.18.4 this silently stopped being the case: matsumotory/ngx_mruby#210 And in ngx_mruby 1.18.5 this incorrect usage was turned into an error: matsumotory/ngx_mruby#217 Moving `mruby_post_read_handler` outside the location block is a no-op for the older ngx_mruby currently used by this buildpack, but ensures compatibility with the newer ngx_mruby being used in the upcoming Heroku-20 support PR. See matsumotory/ngx_mruby#210. * Add support for Heroku-20 (heroku#182) This adds support for the new Heroku-20 stack: https://devcenter.heroku.com/articles/heroku-20-stack The buildpack's binaries were previously generated by: https://github.com/hone/docker-nginx-builder However that repository is quite out of date, and much of its complexity is no longer required thanks to improvements to `ngx_mruby`'s upstream build scripts/process: https://github.com/matsumotory/ngx_mruby/tree/v2.2.3/docs/install https://github.com/matsumotory/ngx_mruby/blob/v2.2.3/build.sh The new build script has been co-located in this buildpack to improve discoverability, and prevent needing to open PRs against multiple repos when performing updates. The buildpack previously used a subdirectory of the Ruby buildpack's S3 bucket, however I've created a new S3 bucket to improve isolation. This PR adds support for building new binaries for all stacks, however for now only switches to them for Heroku-20, so that the newer nginx version can be tested on the new stack for a while before backporting to the others. The newer ngx_mruby required a compatibility fix, however that has already landed in heroku#181. The binaries have been uploaded already, using the newly documented steps in the README. Closes heroku#166. Closes W-8367040. * Release v5 (heroku#183) * Ensure the SSL module is enabled (heroku#186) Previously the compile silently skipped the SSL module: ``` Configuration summary ... + OpenSSL library is not used ``` Which causes failures if SSL related directives are used. Now the `--with-http_ssl_module` flag is passed, which results in: ``` Configuration summary ... + using system OpenSSL library ``` And `nginx -V` now includes an additional line: ``` built with OpenSSL 1.1.1f 31 Mar 2020 ``` See: https://github.com/matsumotory/ngx_mruby/tree/master/docs/install#3-a-using-buildsh Fixes heroku#185. Closes W-8449334. * Update nginx for Heroku-16 and Heroku-18 to 1.19.0 (heroku#190) Upgrades nginx from 1.9.7 to 1.19.0, to match that already used for Heroku-20. In addition, the buildpack now uses the correct binaries for these stacks, rather than using a binary compiled for Cedar-14. Fixes heroku#165. * Release v6 (heroku#191) * Docs: Use the buildpack registry URL in usage example (heroku#194) Since this buildpack exists on the buildpack registry under the name `heroku-community/static`, and using buildpack registry versions is recommended over the GitHub URLs. * Output a helpful error message when no static.json is found (heroku#202) The error message is now output to `stderr` otherwise it's not shown. Closes GUS-W-8799430. Refs heroku#198. * Release v7 (heroku#203) To pick up heroku#202. Refs GUS-W-8799430. * README: Fix spelling of 'instead' (heroku#213) Signed-off-by: Josh Soref <jsoref@users.noreply.github.com> Co-authored-by: Josh Soref <jsoref@users.noreply.github.com> * Updated/Added CODEOWNERS with ECCN * Port Check Changelog improvements from other repos (heroku#237) eg: https://github.com/heroku/heroku-buildpack-python/blob/5d6776f77a89e7ef3ada701d05c473117ecf817a/.github/workflows/check_changelog.yml Notably, one can not use both a label and a PR description attribute, rather than the unsightly PR title annotation. * Bump sinatra from 1.4.7 to 2.2.0 in /spec/support/docker/proxy (heroku#236) Bumps [sinatra](https://github.com/sinatra/sinatra) from 1.4.7 to 2.2.0. - [Release notes](https://github.com/sinatra/sinatra/releases) - [Changelog](https://github.com/sinatra/sinatra/blob/master/CHANGELOG.md) - [Commits](sinatra/sinatra@v1.4.7...v2.2.0) --- updated-dependencies: - dependency-name: sinatra dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * Drop support for Cedar-14 and Heroku-16 (heroku#238) Since they are EOL and it's no longer possible to perform builds using them. Closes heroku#214. GUS-W-10346704. * Update ngx_mruby to 2.2.4 and nginx to 1.21.3 (heroku#240) The binary build process for this buildpack uses the default `nginx` version specified by `ngx_mruby`. As such, updating `ngx_mruby` from `2.2.3` to `2.2.4` means the bundled `nginx` version is also updated from `1.19.0` to `1.21.3`: https://github.com/matsumotory/ngx_mruby/blob/v2.2.3/nginx_version https://github.com/matsumotory/ngx_mruby/blob/v2.2.4/nginx_version Changes: https://github.com/matsumotory/ngx_mruby/releases/tag/v2.2.4 https://nginx.org/en/CHANGES GUS-W-10346704. * Release v8 (heroku#241) To pick up heroku#238 and heroku#240. GUS-W-10346704. * Bump rack from 2.2.3 to 2.2.3.1 in /spec/support/docker/proxy (heroku#242) Bumps [rack](https://github.com/rack/rack) from 2.2.3 to 2.2.3.1. - [Release notes](https://github.com/rack/rack/releases) - [Changelog](https://github.com/rack/rack/blob/main/CHANGELOG.md) - [Commits](rack/rack@2.2.3...2.2.3.1) --- updated-dependencies: - dependency-name: rack dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * Deprecate buildpack (heroku#243) * Deprecate buildpack This build pack is currently not maintained by a team and carries no support obligations. Let's make this clearer by deprecating the build pack. This is done right before the release of heroku-22 as supporting new stacks require maintenance effort. Also before the desire to re-write it as a CNB comes into play. * Bring back Readme contents Having README docs makes it easier for developers to lookup features while they transition off the buildpack. * Update docs for deprecation - Mention the need to re-write mruby parts - Link to a specific nginx build pack and give commands on how to add it - Give specific command to remove this buildpack from app - Mention in README we're open to extra docs/help for people migrating off. - Space after testing header because it's my thing and I looked at those docs. - Added a link to where `Nginx::Request` is defined because it's not obvious it comes from ngx_mruby * Update README.md Co-authored-by: Ed Morley <501702+edmorley@users.noreply.github.com> * Update bin/compile Co-authored-by: Ed Morley <501702+edmorley@users.noreply.github.com> * Address PR comments Co-authored-by: Ed Morley <501702+edmorley@users.noreply.github.com> * v9 (heroku#244) Co-authored-by: schneems <richard.schneeman+foo@gmail.com> Co-authored-by: Ed Morley <501702+edmorley@users.noreply.github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Ben Williams <ben@719ben.com> Co-authored-by: Josh Soref <2119212+jsoref@users.noreply.github.com> Co-authored-by: Josh Soref <jsoref@users.noreply.github.com> Co-authored-by: svc-scm <48930134+svc-scm@users.noreply.github.com> Co-authored-by: niels-van-den-broeck <niels@codecompanion.be>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
ref: #210