From 93ced457d0ba4390aee597e39d1d24c15182afbd Mon Sep 17 00:00:00 2001 From: Richard Schneeman Date: Tue, 7 Jun 2022 09:59:52 -0500 Subject: [PATCH 1/6] 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. --- CHANGELOG.md | 2 + README.md | 317 +++------------------------------------------------ bin/compile | 20 ++++ 3 files changed, 35 insertions(+), 304 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 82019318..00e9cf7a 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -2,6 +2,8 @@ ## Unreleased +* [#243](https://github.com/heroku/heroku-buildpack-static/pull/243) Buildpack is officially deprecated + ## v8 (2022-05-19) * [#240](https://github.com/heroku/heroku-buildpack-static/pull/240) Update ngx_mruby from 2.2.3 to 2.2.4. diff --git a/README.md b/README.md index 64d1d8a2..749b732d 100644 --- a/README.md +++ b/README.md @@ -1,319 +1,28 @@ # heroku-buildpack-static + **NOTE**: This buildpack is in an experimental OSS project. This is a buildpack for handling static sites and single page web apps. For a guide, read the [Getting Started with Single Page Apps on Heroku](https://gist.github.com/hone/24b06869b4c1eca701f9). -## Features -* serving static assets -* gzip on by default -* error/access logs support in `heroku logs` -* custom [configuration](#configuration) - -## Deploying -The `static.json` file is required to use this buildpack. This file handles all the configuration described below. - -1. Set the app to this buildpack: `$ heroku buildpacks:set heroku-community/static`. -2. Deploy: `$ git push heroku master` - -### Configuration -You can configure different options for your static application by writing a `static.json` in the root folder of your application. - -#### Root -This allows you to specify a different asset root for the directory of your application. For instance, if you're using ember-cli, it naturally builds a `dist/` directory, so you might want to use that instead. - -```json -{ - "root": "dist/" -} - -``` - -By default this is set to `public_html/` - -#### Canonical Host -This allows you to perform 301 redirects to a specific hostname, which can be useful for redirecting www to non-www (or vice versa). - -```json -{ - "canonical_host": "www.example.com" -} -``` - -You can use environment variables as well: - -```json -{ - "canonical_host": "${HOST}" -} -``` - -#### Default Character Set -This allows you to specify a character set for your text assets (HTML, Javascript, CSS, and so on). For most apps, this should be the default value of "UTF-8", but you can override it by setting `encoding`: - -```json -{ - "encoding": "US-ASCII" -} -``` - -#### Clean URLs -For SEO purposes, you can drop the `.html` extension from URLs for say a blog site. This means users could go to `/foo` instead of `/foo.html`. - - -```json -{ - "clean_urls": true -} -``` - -By default this is set to `false`. - - -#### Logging -You can disable the access log and change the severity level for the error log. - -```json -{ - "logging": { - "access": false, - "error": "warn" - } -} -``` - -By default `access` is set to `true` and `error` is set to `error`. - -The environment variable `STATIC_DEBUG` can be set, to override the `error` log level to `error`. - - -#### Custom Routes -You can define custom routes that combine to a single file. This allows you to preserve routing for a single page web application. The following operators are supported: - -* `*` supports a single path segment in the URL. In the configuration below, `/baz.html` would match but `/bar/baz.html` would not. -* `**` supports any length in the URL. In the configuration below, both `/route/foo` would work and `/route/foo/bar/baz`. - -```json -{ - "routes": { - "/*.html": "index.html", - "/route/**": "bar/baz.html" - } -} -``` - -##### Browser history and asset files -When serving a single page app, it's useful to support wildcard URLs that serves the index.html file, while also continuing to serve JS and CSS files correctly. Route ordering allows you to do both: - -```json -{ - "routes": { - "/assets/*": "/assets/", - "/**": "index.html" - } -} -``` - -#### Custom Redirects -With custom redirects, you can move pages to new routes but still preserve the old routes for SEO purposes. By default, we return a `301` status code, but you can specify the status code you want. - -```json -{ - "redirects": { - "/old/gone/": { - "url": "/", - "status": 302 - } - } -} -``` - -##### Interpolating Env Var Values -It's common to want to be able to test the frontend against various backends. The `url` key supports environment variable substitution using `${ENV_VAR_NAME}`. For instance, if there was a staging and production Heroku app for your API, you could setup the config above like the following: - -```json -{ - "redirects": { - "/old/gone/": { - "url": "${NEW_SITE_DOMAIN}/new/here/" - } - } -} -``` - -Then using the [config vars](https://devcenter.heroku.com/articles/config-vars), you can point the frontend app to the appropriate backend. To match the original proxy setup: - -```bash -$ heroku config:set NEW_SITE_DOMAIN="https://example.herokapp.com" -``` - -#### Custom Error Pages -You can replace the default nginx 404 and 500 error pages by defining the path to one in your config. - -```json -{ - "error_page": "errors/error.html" -} -``` - -#### HTTPS Only - -You can redirect all HTTP requests to HTTPS. - -``` -{ - "https_only": true -} -``` - -#### Basic Authentication - -You can enable Basic Authentication so all requests require authentication. - -``` -{ - "basic_auth": true -} -``` - -This will generate `.htpasswd` using environment variables `BASIC_AUTH_USERNAME` and `BASIC_AUTH_PASSWORD` if they are present. Otherwise it will use a standard `.htpasswd` file present in the `app` directory. - -Passwords set via `BASIC_AUTH_PASSWORD` can be generated using OpenSSL or Apache Utils. For instance: `openssl passwd -apr1`. - -#### Proxy Backends -For single page web applications like Ember, it's common to back the application with another app that's hosted on Heroku. The down side of separating out these two applications is that now you have to deal with CORS. To get around this (but at the cost of some latency) you can have the static buildpack proxy apps to your backend at a mountpoint. For instance, we can have all the api requests live at `/api/` which actually are just requests to our API server. - -```json -{ - "proxies": { - "/api/": { - "origin": "https://hone-ember-todo-rails.herokuapp.com/" - } - } -} -``` - -##### Interpolating Env Var Values -It's common to want to be able to test the frontend against various backends. The `origin` key supports environment variable substitution using `${ENV_VAR_NAME}`. For instance, if there was a staging and production Heroku app for your API, you could setup the config above like the following: - -```json -{ - "proxies": { - "/api/": { - "origin": "https://${API_APP_NAME}.herokuapp.com/" - } - } -} -``` - -Then using the [config vars](https://devcenter.heroku.com/articles/config-vars), you can point the frontend app to the appropriate backend. To match the original proxy setup: - -```bash -$ heroku config:set API_APP_NAME="hone-ember-todo-rails" -``` - -#### Custom Headers -Using the headers key, you can set custom response headers. It uses the same operators for pathing as [Custom Routes](#custom-routes). - -```json -{ - "headers": { - "/": { - "Cache-Control": "no-store, no-cache" - }, - "/assets/**": { - "Cache-Control": "public, max-age=512000" - }, - "/assets/webfonts/*": { - "Access-Control-Allow-Origin": "*" - } - } -} -``` - -For example, to enable CORS for all resources, you just need to enable it for all routes like this: - -```json -{ - "headers": { - "/**": { - "Access-Control-Allow-Origin": "*" - } - } -} -``` - -##### Precedence -When there are header conflicts, the last header definition always wins. The headers do not get appended. For example, - -```json -{ - "headers": { - "/**": { - "X-Foo": "bar", - "X-Bar": "baz" - }, - "/foo": { - "X-Foo": "foo" - } - } -} -``` - -when accessing `/foo`, `X-Foo` will have the value `"foo"` and `X-Bar` will not be present. - -### Route Ordering - -* HTTPS redirect -* Root Files -* Clean URLs -* Proxies -* Redirects -* Custom Routes -* 404 - -### Procfile / multiple buildpacks - -In case you have multiple buildpacks for the application you can ensure static rendering in `Procfile` with `web: bin/boot`. - -## Testing -For testing we use Docker to replicate Heroku locally. You'll need to have [it setup locally](https://docs.docker.com/installation/). We're also using rspec for testing with Ruby. You'll need to have those setup and install those deps: - -```sh -$ bundle install -``` - -To run the test suite just execute: - -```sh -$ bundle exec rspec -``` - -### Structure -To add a new test, add another example inside `spec/simple_spec.rb` or create a new file based off of `spec/simple_spec.rb`. All the example apps live in `spec/fixtures`. - -When writing a test, `BuildpackBuilder` creates the docker container we need that represents the heroku cedar-14 stack. `AppRunner.new` takes the name of a fixture and mounts it in the container built by `BuildpackBuilder` to run tests against. The `AppRunner` instance provides convenience methods like `get` that just wrap `net/http` for analyzing the response. +# heroku-buildpack-static -### Boot2docker +## WARNING: `heroku-buildpack-static` is deprecated -If you are running docker with boot2docker, the buildpack will automatically send tests to the right ip address. -You need to forward the docker's port 3000 to the virtual machine's port though. +This buildpack is deprecated and is no longer being maintained. +If you are using this project, you can transition over to NGINX via an NGINX buildpack. +Use your project's existing configuration. +To find the NGINX configuration generated by the heroku-buildpack-static you can run: ``` -VBoxManage modifyvm "boot2docker-vm" --natpf1 "tcp-port3000,tcp,,3000,,3000"; +$ heroku run bash +~ $ bin/config/make-config +~ $ cat config/nginx.conf ``` -## Releasing new binaries +These commands will output your current NGINX config generated from your `static.json` contents. Write +these contents to your local repo, commit them to disk and configure an NGINX buildpack to +serve your application with that configuration. -The steps buildpack maintainers need to perform when releasing new nginx -binaries (either for a new stack or `ngx_mruby` version), are: -1. Update the stacks list in `Makefile` and/or the ngx_mruby version - in `scripts/build_ngx_mruby.sh`. -2. Run `make build` to build all stacks or `make build-heroku-NN` to build just one stack. -3. Ensure the AWS CLI is installed (eg `brew install awscli`). -4. Authenticate with the relevant AWS account (typically by setting the environment variables from PCSK). -5. Run `make sync` (or if using a custom S3 bucket, `S3_BUCKET=... make sync`). -6. Update `bin/compile` to reference the new stacks and/or nginx version URLs. -7. Open a PR with the changes from (1) and (6). diff --git a/bin/compile b/bin/compile index 51c4d72f..889aefa5 100755 --- a/bin/compile +++ b/bin/compile @@ -8,6 +8,26 @@ cache_dir=$2 env_dir=$3 bp_dir=$(dirname $(dirname $0)) +cat <<'EOF' + ## WARNING: `heroku-buildpack-static` is deprecated + + This buildpack is deprecated and is no longer being maintained. + If you are using this project, you can transition over to NGINX via an NGINX buildpack. + Use your project's existing configuration. + To find the NGINX configuration generated by the heroku-buildpack-static you can run: + + ``` + $ heroku run bash + ~ $ bin/config/make-config + ~ $ cat config/nginx.conf + ``` + + These commands will output your current NGINX config generated from your `static.json` contents. Write + these contents to your local repo, commit them to disk and configure an NGINX buildpack to + serve your application with that configuration. + +EOF + case "${STACK}" in heroku-18|heroku-20) nginx_archive_url="https://heroku-buildpack-static.s3.amazonaws.com/${STACK}/nginx-1.21.3-ngx_mruby-2.2.4.tgz" From 90a727248de1286ca8e869caade5cafa6922cdc1 Mon Sep 17 00:00:00 2001 From: Richard Schneeman Date: Thu, 9 Jun 2022 12:24:35 -0500 Subject: [PATCH 2/6] Bring back Readme contents Having README docs makes it easier for developers to lookup features while they transition off the buildpack. --- README.md | 311 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 311 insertions(+) diff --git a/README.md b/README.md index 749b732d..02e60bb3 100644 --- a/README.md +++ b/README.md @@ -25,4 +25,315 @@ These commands will output your current NGINX config generated from your `static these contents to your local repo, commit them to disk and configure an NGINX buildpack to serve your application with that configuration. +## Features +* serving static assets +* gzip on by default +* error/access logs support in `heroku logs` +* custom [configuration](#configuration) +## Deploying +The `static.json` file is required to use this buildpack. This file handles all the configuration described below. + +1. Set the app to this buildpack: `$ heroku buildpacks:set heroku-community/static`. +2. Deploy: `$ git push heroku master` + +### Configuration +You can configure different options for your static application by writing a `static.json` in the root folder of your application. + +#### Root +This allows you to specify a different asset root for the directory of your application. For instance, if you're using ember-cli, it naturally builds a `dist/` directory, so you might want to use that instead. + +```json +{ + "root": "dist/" +} + +``` + +By default this is set to `public_html/` + +#### Canonical Host +This allows you to perform 301 redirects to a specific hostname, which can be useful for redirecting www to non-www (or vice versa). + +```json +{ + "canonical_host": "www.example.com" +} +``` + +You can use environment variables as well: + +```json +{ + "canonical_host": "${HOST}" +} +``` + +#### Default Character Set +This allows you to specify a character set for your text assets (HTML, Javascript, CSS, and so on). For most apps, this should be the default value of "UTF-8", but you can override it by setting `encoding`: + +```json +{ + "encoding": "US-ASCII" +} +``` + +#### Clean URLs +For SEO purposes, you can drop the `.html` extension from URLs for say a blog site. This means users could go to `/foo` instead of `/foo.html`. + + +```json +{ + "clean_urls": true +} +``` + +By default this is set to `false`. + + +#### Logging +You can disable the access log and change the severity level for the error log. + +```json +{ + "logging": { + "access": false, + "error": "warn" + } +} +``` + +By default `access` is set to `true` and `error` is set to `error`. + +The environment variable `STATIC_DEBUG` can be set, to override the `error` log level to `error`. + + +#### Custom Routes +You can define custom routes that combine to a single file. This allows you to preserve routing for a single page web application. The following operators are supported: + +* `*` supports a single path segment in the URL. In the configuration below, `/baz.html` would match but `/bar/baz.html` would not. +* `**` supports any length in the URL. In the configuration below, both `/route/foo` would work and `/route/foo/bar/baz`. + +```json +{ + "routes": { + "/*.html": "index.html", + "/route/**": "bar/baz.html" + } +} +``` + +##### Browser history and asset files +When serving a single page app, it's useful to support wildcard URLs that serves the index.html file, while also continuing to serve JS and CSS files correctly. Route ordering allows you to do both: + +```json +{ + "routes": { + "/assets/*": "/assets/", + "/**": "index.html" + } +} +``` + +#### Custom Redirects +With custom redirects, you can move pages to new routes but still preserve the old routes for SEO purposes. By default, we return a `301` status code, but you can specify the status code you want. + +```json +{ + "redirects": { + "/old/gone/": { + "url": "/", + "status": 302 + } + } +} +``` + +##### Interpolating Env Var Values +It's common to want to be able to test the frontend against various backends. The `url` key supports environment variable substitution using `${ENV_VAR_NAME}`. For instance, if there was a staging and production Heroku app for your API, you could setup the config above like the following: + +```json +{ + "redirects": { + "/old/gone/": { + "url": "${NEW_SITE_DOMAIN}/new/here/" + } + } +} +``` + +Then using the [config vars](https://devcenter.heroku.com/articles/config-vars), you can point the frontend app to the appropriate backend. To match the original proxy setup: + +```bash +$ heroku config:set NEW_SITE_DOMAIN="https://example.herokapp.com" +``` + +#### Custom Error Pages +You can replace the default nginx 404 and 500 error pages by defining the path to one in your config. + +```json +{ + "error_page": "errors/error.html" +} +``` + +#### HTTPS Only + +You can redirect all HTTP requests to HTTPS. + +``` +{ + "https_only": true +} +``` + +#### Basic Authentication + +You can enable Basic Authentication so all requests require authentication. + +``` +{ + "basic_auth": true +} +``` + +This will generate `.htpasswd` using environment variables `BASIC_AUTH_USERNAME` and `BASIC_AUTH_PASSWORD` if they are present. Otherwise it will use a standard `.htpasswd` file present in the `app` directory. + +Passwords set via `BASIC_AUTH_PASSWORD` can be generated using OpenSSL or Apache Utils. For instance: `openssl passwd -apr1`. + +#### Proxy Backends +For single page web applications like Ember, it's common to back the application with another app that's hosted on Heroku. The down side of separating out these two applications is that now you have to deal with CORS. To get around this (but at the cost of some latency) you can have the static buildpack proxy apps to your backend at a mountpoint. For instance, we can have all the api requests live at `/api/` which actually are just requests to our API server. + +```json +{ + "proxies": { + "/api/": { + "origin": "https://hone-ember-todo-rails.herokuapp.com/" + } + } +} +``` + +##### Interpolating Env Var Values +It's common to want to be able to test the frontend against various backends. The `origin` key supports environment variable substitution using `${ENV_VAR_NAME}`. For instance, if there was a staging and production Heroku app for your API, you could setup the config above like the following: + +```json +{ + "proxies": { + "/api/": { + "origin": "https://${API_APP_NAME}.herokuapp.com/" + } + } +} +``` + +Then using the [config vars](https://devcenter.heroku.com/articles/config-vars), you can point the frontend app to the appropriate backend. To match the original proxy setup: + +```bash +$ heroku config:set API_APP_NAME="hone-ember-todo-rails" +``` + +#### Custom Headers +Using the headers key, you can set custom response headers. It uses the same operators for pathing as [Custom Routes](#custom-routes). + +```json +{ + "headers": { + "/": { + "Cache-Control": "no-store, no-cache" + }, + "/assets/**": { + "Cache-Control": "public, max-age=512000" + }, + "/assets/webfonts/*": { + "Access-Control-Allow-Origin": "*" + } + } +} +``` + +For example, to enable CORS for all resources, you just need to enable it for all routes like this: + +```json +{ + "headers": { + "/**": { + "Access-Control-Allow-Origin": "*" + } + } +} +``` + +##### Precedence +When there are header conflicts, the last header definition always wins. The headers do not get appended. For example, + +```json +{ + "headers": { + "/**": { + "X-Foo": "bar", + "X-Bar": "baz" + }, + "/foo": { + "X-Foo": "foo" + } + } +} +``` + +when accessing `/foo`, `X-Foo` will have the value `"foo"` and `X-Bar` will not be present. + +### Route Ordering + +* HTTPS redirect +* Root Files +* Clean URLs +* Proxies +* Redirects +* Custom Routes +* 404 + +### Procfile / multiple buildpacks + +In case you have multiple buildpacks for the application you can ensure static rendering in `Procfile` with `web: bin/boot`. + +## Testing +For testing we use Docker to replicate Heroku locally. You'll need to have [it setup locally](https://docs.docker.com/installation/). We're also using rspec for testing with Ruby. You'll need to have those setup and install those deps: + +```sh +$ bundle install +``` + +To run the test suite just execute: + +```sh +$ bundle exec rspec +``` + +### Structure +To add a new test, add another example inside `spec/simple_spec.rb` or create a new file based off of `spec/simple_spec.rb`. All the example apps live in `spec/fixtures`. + +When writing a test, `BuildpackBuilder` creates the docker container we need that represents the heroku cedar-14 stack. `AppRunner.new` takes the name of a fixture and mounts it in the container built by `BuildpackBuilder` to run tests against. The `AppRunner` instance provides convenience methods like `get` that just wrap `net/http` for analyzing the response. + +### Boot2docker + +If you are running docker with boot2docker, the buildpack will automatically send tests to the right ip address. +You need to forward the docker's port 3000 to the virtual machine's port though. + +``` +VBoxManage modifyvm "boot2docker-vm" --natpf1 "tcp-port3000,tcp,,3000,,3000"; +``` + +## Releasing new binaries + +The steps buildpack maintainers need to perform when releasing new nginx +binaries (either for a new stack or `ngx_mruby` version), are: + +1. Update the stacks list in `Makefile` and/or the ngx_mruby version + in `scripts/build_ngx_mruby.sh`. +2. Run `make build` to build all stacks or `make build-heroku-NN` to build just one stack. +3. Ensure the AWS CLI is installed (eg `brew install awscli`). +4. Authenticate with the relevant AWS account (typically by setting the environment variables from PCSK). +5. Run `make sync` (or if using a custom S3 bucket, `S3_BUCKET=... make sync`). +6. Update `bin/compile` to reference the new stacks and/or nginx version URLs. +7. Open a PR with the changes from (1) and (6). From aca14897b721c119a82e29dd8f5eec0315bf9472 Mon Sep 17 00:00:00 2001 From: Richard Schneeman Date: Thu, 9 Jun 2022 13:00:37 -0500 Subject: [PATCH 3/6] 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 --- README.md | 14 +++++++++++--- bin/compile | 9 ++++++--- scripts/config/lib/ngx_mruby/routes_path.rb | 2 +- 3 files changed, 18 insertions(+), 7 deletions(-) diff --git a/README.md b/README.md index 02e60bb3..2e92c860 100644 --- a/README.md +++ b/README.md @@ -21,9 +21,16 @@ $ heroku run bash ~ $ cat config/nginx.conf ``` -These commands will output your current NGINX config generated from your `static.json` contents. Write -these contents to your local repo, commit them to disk and configure an NGINX buildpack to -serve your application with that configuration. +These commands will output your current NGINX config generated from your `static.json` contents. + +- Write these contents to your local repo at `config/nginx.conf.erb`, commit them to git. +- Replace path logic that previously used `mruby` with static logic. +- Configure your app to use the NGINX buildpack via `heroku buildpacks:add https://github.com/heroku/heroku-buildpack-nginx`. +- Remove this buildpack via `heroku buildpacks:remove https://github.com/heroku/heroku-buildpack-static` + +## Deprecation PRs + +If you have tips or tricks for migrating off of this buildpack and want to add them to the instructions above please send a PR. ## Features * serving static assets @@ -298,6 +305,7 @@ when accessing `/foo`, `X-Foo` will have the value `"foo"` and `X-Bar` will not In case you have multiple buildpacks for the application you can ensure static rendering in `Procfile` with `web: bin/boot`. ## Testing + For testing we use Docker to replicate Heroku locally. You'll need to have [it setup locally](https://docs.docker.com/installation/). We're also using rspec for testing with Ruby. You'll need to have those setup and install those deps: ```sh diff --git a/bin/compile b/bin/compile index 889aefa5..a9289a6c 100755 --- a/bin/compile +++ b/bin/compile @@ -22,9 +22,12 @@ cat <<'EOF' ~ $ cat config/nginx.conf ``` - These commands will output your current NGINX config generated from your `static.json` contents. Write - these contents to your local repo, commit them to disk and configure an NGINX buildpack to - serve your application with that configuration. + These commands will output your current NGINX config generated from your `static.json` contents. + + - Write these contents to your local repo at `config/nginx.conf.erb`, commit them to git. + - Replace path logic that previously used `mruby` with static logic. + - Configure your app to use the NGINX buildpack via `heroku buildpacks:add https://github.com/heroku/heroku-buildpack-nginx`. + - Remove this buildpack via `heroku buildpacks:remove https://github.com/heroku/heroku-buildpack-static` EOF diff --git a/scripts/config/lib/ngx_mruby/routes_path.rb b/scripts/config/lib/ngx_mruby/routes_path.rb index 1fabbcbe..f4cdb9ec 100644 --- a/scripts/config/lib/ngx_mruby/routes_path.rb +++ b/scripts/config/lib/ngx_mruby/routes_path.rb @@ -5,7 +5,7 @@ config = {} config = JSON.parse(File.read(USER_CONFIG)) if File.exist?(USER_CONFIG) -req = Nginx::Request.new +req = Nginx::Request.new # defined by https://github.com/matsumotory/ngx_mruby/blob/c7682cfb4c0984a41f1a447b71ae01e1f4fcc6bf/docs/class_and_method/README.md#nginxrequest-class uri = req.var.uri nginx_route = req.var.route routes = NginxConfigUtil.parse_routes(config["routes"]) From 245c254efc504ddf6e7e9aced1cbf656f0775b92 Mon Sep 17 00:00:00 2001 From: Richard Schneeman Date: Thu, 9 Jun 2022 14:39:46 -0500 Subject: [PATCH 4/6] Update README.md Co-authored-by: Ed Morley <501702+edmorley@users.noreply.github.com> --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 2e92c860..c67ac7cb 100644 --- a/README.md +++ b/README.md @@ -25,7 +25,7 @@ These commands will output your current NGINX config generated from your `static - Write these contents to your local repo at `config/nginx.conf.erb`, commit them to git. - Replace path logic that previously used `mruby` with static logic. -- Configure your app to use the NGINX buildpack via `heroku buildpacks:add https://github.com/heroku/heroku-buildpack-nginx`. +- Configure your app to use the NGINX buildpack via `heroku buildpacks:add heroku-community/nginx`. - Remove this buildpack via `heroku buildpacks:remove https://github.com/heroku/heroku-buildpack-static` ## Deprecation PRs From 1b2eac2984ad83ff827f244fd1732a42e3d950f6 Mon Sep 17 00:00:00 2001 From: Richard Schneeman Date: Thu, 9 Jun 2022 14:39:56 -0500 Subject: [PATCH 5/6] Update bin/compile Co-authored-by: Ed Morley <501702+edmorley@users.noreply.github.com> --- bin/compile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bin/compile b/bin/compile index a9289a6c..754ddd0b 100755 --- a/bin/compile +++ b/bin/compile @@ -26,7 +26,7 @@ cat <<'EOF' - Write these contents to your local repo at `config/nginx.conf.erb`, commit them to git. - Replace path logic that previously used `mruby` with static logic. - - Configure your app to use the NGINX buildpack via `heroku buildpacks:add https://github.com/heroku/heroku-buildpack-nginx`. + - Configure your app to use the NGINX buildpack via `heroku buildpacks:add heroku-community/nginx`. - Remove this buildpack via `heroku buildpacks:remove https://github.com/heroku/heroku-buildpack-static` EOF From 0b476ac6929837f4139fe2b2d22c2f2d83a11082 Mon Sep 17 00:00:00 2001 From: Richard Schneeman Date: Thu, 9 Jun 2022 14:42:23 -0500 Subject: [PATCH 6/6] Address PR comments --- README.md | 4 +--- bin/compile | 2 +- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index c67ac7cb..2b40e705 100644 --- a/README.md +++ b/README.md @@ -6,8 +6,6 @@ This is a buildpack for handling static sites and single page web apps. For a guide, read the [Getting Started with Single Page Apps on Heroku](https://gist.github.com/hone/24b06869b4c1eca701f9). -# heroku-buildpack-static - ## WARNING: `heroku-buildpack-static` is deprecated This buildpack is deprecated and is no longer being maintained. @@ -26,7 +24,7 @@ These commands will output your current NGINX config generated from your `static - Write these contents to your local repo at `config/nginx.conf.erb`, commit them to git. - Replace path logic that previously used `mruby` with static logic. - Configure your app to use the NGINX buildpack via `heroku buildpacks:add heroku-community/nginx`. -- Remove this buildpack via `heroku buildpacks:remove https://github.com/heroku/heroku-buildpack-static` +- Remove this buildpack via `heroku buildpacks:remove heroku-community/static` (or `heroku buildpacks:remove https://github.com/heroku/heroku-buildpack-static`). ## Deprecation PRs diff --git a/bin/compile b/bin/compile index 754ddd0b..7094b3d4 100755 --- a/bin/compile +++ b/bin/compile @@ -27,7 +27,7 @@ cat <<'EOF' - Write these contents to your local repo at `config/nginx.conf.erb`, commit them to git. - Replace path logic that previously used `mruby` with static logic. - Configure your app to use the NGINX buildpack via `heroku buildpacks:add heroku-community/nginx`. - - Remove this buildpack via `heroku buildpacks:remove https://github.com/heroku/heroku-buildpack-static` + - Remove this buildpack via `heroku buildpacks:remove heroku-community/static` (or `heroku buildpacks:remove https://github.com/heroku/heroku-buildpack-static`). EOF