rundoc 2.0.1 → 3.0.1

data/test/fixtures/cnb/shared/configure_builder.md

@@ -0,0 +1,23 @@
+## Configure the default pack builder
+
+Once `pack` is installed, the only configuration you'll need for this tutorial is to set a default builder:
+
+```
+:::>> $ pack config default-builder heroku/builder:22
+```
+
+You can view your default builder at any time:
+
+```
+:::>> $ pack config default-builder
+```
+
+The following tutorial is built on amd64 architecture (also known as x86). If you are building on a machine with different architecture (such as arm64/aarch64 for a Mac) you will need to tell Docker to use `linux/amd64` architecture. You can do this via a `--platform linux/amd64` flag or by exporting an environment variable:
+
+```
+$ export DOCKER_DEFAULT_PLATFORM=linux/amd64
+:::-- rundoc.configure
+# Needed because all `$` commands are run as separate isolated processes
+
+ENV["DOCKER_DEFAULT_PLATFORM"] = "linux/amd64"
+```

data/test/fixtures/cnb/shared/install_pack.md

@@ -0,0 +1,14 @@
+## Install the pack CLI
+
+We assume you have [docker installed](https://docs.docker.com/engine/install/) and a working copy [of git](https://github.com/git-guides/install-git). Next, you will need to install the CLI tool for building CNBs, [pack CLI](https://buildpacks.io/docs/for-platform-operators/how-to/integrate-ci/pack/). If you're on a Mac you can install it via Homebrew:
+
+```
+:::-> print.text
+$ brew install buildpacks/tap/pack
+```
+
+Ensure that `pack` is installed correctly:
+
+```
+:::>> $ pack --version
+```

data/test/fixtures/cnb/shared/pack_build.md

@@ -0,0 +1,20 @@
+## Build the application image with the pack CLI
+
+Now build an image named `my-image-name` by executing the heroku builder against the application by running the
+`pack build` command:
+
+```
+$ pack build my-image-name --path .
+:::-- $ docker rmi -f my-image-name
+:::-- $ pack build my-image-name --path . 2>&1 | tee build_output.txt
+:::-> $ cat build_output.txt
+```
+
+> [!NOTE]
+> Your output may differ.
+
+Verify that you see “Successfully built image my-image-name” at the end of the output. And verify that the image is present locally:
+
+```
+:::>> $ docker image ls --format "table {{.ID}}\t{{.Repository}}\t{{.Tag}}" | grep my-image-name
+```

data/test/fixtures/cnb/shared/procfile.md

@@ -0,0 +1,13 @@
+## Configuring your web process with the Procfile
+
+Most buildpacks rely on existing community standards to allow you to configure your application declaratively. They can also implement custom logic based on file contents on disk or environment variables present at build time.
+
+The `Procfile` is a configuration file format that was [introduced by Heroku in 2011](https://devcenter.heroku.com/articles/procfile), you can now use this behavior on your CNB-powered application via the `heroku/procfile`, which like the rest of the buildpacks in our builder [is open source](https://github.com/heroku/buildpacks-procfile). The `heroku/procfile` buildpack allows you to configure your web startup process.
+
+This is the `Procfile` of the getting started guide:
+
+```
+:::-> $ cat Procfile
+```
+
+By including this file and using `heroku/procfile` buildpack, your application will receive a default web process. You can configure this behavior by changing the contents of that file.

data/test/fixtures/cnb/shared/use_the_image.md

@@ -0,0 +1,52 @@
+## Use the image
+
+Even though we used `pack` and CNBs to build our image, it can be run with your favorite tools like any other OCI image. We will be using the `docker` command line to run our image.
+
+By default, images will be booted into a web server configuration. You can launch the app we just built by running:
+
+```
+$ docker run -it --rm --env PORT=9292 -p 9292:9292 my-image-name
+:::-> background.start("docker run --rm --env PORT=9292 -p 9292:9292 my-image-name", name: "docker_server")
+:::-- $ sleep 10
+:::-> background.log.read(name: "docker_server")
+```
+
+Now when you visit [http://localhost:9292](http://localhost:9292) you should see a working web application:
+
+```
+:::>> website.visit(name: "localhost", url: "http://localhost:9292")
+:::>> website.screenshot(name: "localhost")
+```
+
+Don't forget to stop the docker container when you're done.
+
+```
+:::-- $ docker stop $(docker ps -q --filter ancestor=my-image-name )
+:::-- background.stop(name: "docker_server")
+```
+
+Here's a quick breakdown of that command we just ran:
+
+- `docker run` Create and run a new container from an image.
+- `-it` Makes the container interactive and allocates a TTY.
+- `--rm` Automatically remove the container when it exits.
+- `--env PORT=9292` Creates an environment variable named `PORT` and sets it to `9292` this is needed so the application inside the container knows what port to bind the web server.
+- `-p 9292:9292` Publishes a container's port(s) to the host. This is what allows requests from your machine to be received by the container.
+- `my-image-name` The name of the image you want to use for the application.
+
+So far, we've downloaded an application via git and run a single command `pack build` to generate an image, and then we can use that image as if it was generated via a Dockerfile via the `docker run` command.
+
+In addition to running the image as a web server, you can access the container's terminal interactively. In a new terminal window try running this command:
+
+```
+$ docker run -it --rm my-image-name bash
+```
+
+Now you can inspect the container interactively. For example, you can see the files on disk with `ls`:
+
+```
+$ ls
+:::-> $ docker run --rm my-image-name ls
+```
+
+And anything else you would typically do via an interactive container session.

data/test/fixtures/cnb/shared/what_is_a_builder.md

@@ -0,0 +1,18 @@
+## What is a builder?
+
+> [!NOTE]
+> Skip ahead if you want to build the application first and get into the details later. You won't need to
+> know about builders for the rest of this tutorial.
+
+In short, a builder is a delivery mechanism for buildpacks. A builder contains references to base images and individual buildpacks. A base image contains the operating system and system dependencies. Buildpacks are the components that will configure an image to run your application, that’s where the bulk of the logic lives and why the project is called “Cloud Native Buildpacks” and not “Cloud Native Builders.”
+
+You can view the contents of a builder via the command `pack builder inspect`. For example:
+
+```
+:::>> $ pack builder inspect heroku/builder:22 | grep Buildpacks: -m1 -A10
+```
+
+> [!NOTE]
+> Your output version numbers may differ.
+
+This output shows the various buildpacks that represent the different languages that are supported by this builder such as `heroku/go` and `heroku/nodejs-engine`.

data/test/fixtures/rails_4/rundoc.md

@@ -19,7 +19,7 @@ end
 > If you are starting a new application, we recommend you use the most recently released version of Rails.
 
 >warning
->As of November 28th, 2022, free Heroku dynos, free Heroku Postgres and free Heroku Data for Redis plans are [no longer available](https://blog.heroku.com/next-chapter).
+>As of November 28th, 2022, free Heroku dynos, free Heroku Postgres and free Heroku Data for Key-Value Store plans are [no longer available](https://blog.heroku.com/next-chapter).
 >
 >We recommend using our [low-cost plans](https://blog.heroku.com/new-low-cost-plans) to complete this tutorial. Eligible students can apply for platform credits through our new [Heroku for GitHub Students program](https://blog.heroku.com/github-student-developer-program).
 

data/test/fixtures/rails_5/rundoc.md

@@ -22,7 +22,7 @@ end
 > If you are starting a new application, we recommend you use the most recently released version of Rails.
 
 >warning
->As of November 28th, 2022, free Heroku dynos, free Heroku Postgres and free Heroku Data for Redis plans are [no longer available](https://blog.heroku.com/next-chapter).
+>As of November 28th, 2022, free Heroku dynos, free Heroku Postgres and free Heroku Key-Value Store plans are [no longer available](https://blog.heroku.com/next-chapter).
 >
 >We recommend using our [low-cost plans](https://blog.heroku.com/new-low-cost-plans) to complete this tutorial. Eligible students can apply for platform credits through our new [Heroku for GitHub Students program](https://blog.heroku.com/github-student-developer-program).
 

data/test/fixtures/rails_7/rundoc.md

@@ -3,7 +3,6 @@
 email = ENV['HEROKU_EMAIL'] || `heroku auth:whoami`
 
 Rundoc.configure do |config|
-  config.project_root = "myapp"
   config.filter_sensitive(email => "developer@example.com")
   config.filter_sensitive(Dir.pwd => ".")
 end

data/test/fixtures/rails_8/rundoc.md

@@ -0,0 +1,481 @@
+```
+:::-- rundoc
+email = ENV['HEROKU_EMAIL'] || `heroku auth:whoami`
+
+Rundoc.configure do |config|
+  config.filter_sensitive(email => "developer@example.com")
+  config.filter_sensitive(Dir.pwd => ".")
+end
+```
+
+<!--
+  rundoc src:
+  https://github.com/schneems/rundoc/blob/main/test/fixtures/rails_8/rundoc.md
+
+  Command:
+  $ bin/rundoc test/fixtures/rails_8/rundoc.md
+-->
+
+Ruby on Rails is a popular web framework written in [Ruby](http://www.ruby-lang.org/). This guide covers using Rails 8 on Heroku. For information on running previous versions of Rails on Heroku, see the tutorial for [Rails 7.x](getting-started-with-rails7) or [Rails 6.x](getting-started-with-rails6).
+
+```
+:::-- $ ruby -e "exit 1 unless RUBY_VERSION == '3.2.6'"
+```
+
+The tutorial assumes that you have:
+
+- Basic familiarity with Ruby, Ruby on Rails, and Git
+- A locally installed version of Ruby 3.2.0+, Rubygems, Bundler, and Rails 8+
+- A locally installed version of the [Heroku CLI](heroku-cli#install-the-heroku-cli)
+- A [verified Heroku Account](https://devcenter.heroku.com/articles/account-verification)
+- A subscription to the [Eco dynos plan](eco-dyno-hours) (recommended)
+
+>note
+>Using dynos and databases to complete this tutorial counts towards your usage. We recommend using our [low-cost plans](https://blog.heroku.com/new-low-cost-plans) to complete this tutorial. Eligible students can apply for platform credits through our new [Heroku for GitHub Students program](https://blog.heroku.com/github-student-developer-program).
+
+## Local Setup
+
+After installing the [Heroku CLI](heroku-cli#install-the-heroku-cli), log in through your terminal:
+
+```term
+$ heroku login
+heroku: Press any key to open up the browser to login or q to exit
+ ›   Warning: If browser does not open, visit
+ ›   https://cli-auth.heroku.com/auth/browser/***
+heroku: Waiting for login...
+Logging in... done
+Logged in as developer@example.com
+```
+
+This command opens your web browser to the Heroku login page. If your browser is already logged in to Heroku, click the **`Log in`** button on the page.
+
+This authentication is required for the `heroku` and `git` commands to work correctly.
+
+>note
+> If you're behind a firewall that uses a proxy to connect with external HTTP/HTTPS services, [set the `HTTP_PROXY` or `HTTPS_PROXY` environment variables](articles/using-the-cli#using-an-http-proxy) in your local development environment before running the `heroku` command.
+
+## Create a New or Upgrade an Existing Rails App
+
+Ensure you have Rails 8 installed by running `rails -v` before creating an app. If necessary, install Rails 8 with `gem install`:
+
+```term
+:::>> $ gem install rails --no-document
+```
+
+Create a Rails app:
+
+```term
+:::>- $ rails new myapp --database=postgresql
+```
+
+Move into the application directory
+
+```term
+:::>- $ cd myapp
+:::>> $ ls -1
+```
+
+<!-- The `bundle install` after `bundle lock` can be removed after https://github.com/rails/rails/issues/48278 is closed -->
+
+Create a local database:
+
+```term
+:::>> $ bin/rails db:create
+```
+
+## Add the pg Gem
+
+For new or existing apps where `--database=postgresql` isn’t defined, confirm the `sqlite3` gem doesn’t exist in the `Gemfile`. Add the `pg` gem in its place.
+
+Within the `Gemfile` remove:
+
+```ruby
+gem 'sqlite3'
+```
+
+Replace it with:
+
+```ruby
+gem 'pg'
+```
+
+> callout
+>Heroku highly recommends using PostgreSQL locally during development. Maintaining [parity between development](http://www.12factor.net/dev-prod-parity) and deployment environments prevents introducing subtle bugs due to the differences in environments.
+>
+> [Install Postgres locally](heroku-postgresql#local-setup). For more information on why Postgres is recommended instead of Sqlite3, see [why Sqlite3 is not compatible with Heroku](sqlite3).
+
+With the `Gemfile` updated, reinstall the dependencies:
+
+```ruby
+$ bundle install
+```
+
+The installation also updates `Gemfile.lock` with the changes.
+
+In addition to the `pg` gem, ensure that `config/database.yml` defines the `postgresql` adapter. The development section of `config/database.yml` file looks something like this:
+
+```term
+:::>>  $ cat config/database.yml
+```
+
+Be careful here. If the value of `adapter` is `postgres` and not `postgresql`, the application won’t work.
+
+## Create a Welcome Page
+
+Rails 8 no longer has a static index page in production by default. Apps upgraded to Rails 8 keep their existing page configurations, but new Rails 8 apps don't automatically generate a welcome page. Create a `welcome` controller to hold the homepage:
+
+```term
+:::>- $ rails generate controller welcome
+```
+
+Create `app/views/welcome/index.html.erb` and add the following code:
+
+```html
+:::-> file.write app/views/welcome/index.html.erb
+<h2>Hello World</h2>
+<p>
+  The time is now: <%= Time.now %>
+</p>
+```
+
+With a welcome page created, create a route to map to this action.
+
+```ruby
+:::>> file.append config/routes.rb#2
+  root 'welcome#index'
+```
+
+Verify the page is present by starting the Rails web server:
+
+```term
+:::>> background.start("rails server", name: "server")
+:::-- background.stop(name: "server")
+```
+
+Visit [http://localhost:3000](http://localhost:3000) in a browser. If the page doesn’t display, [reference the logs](#view-application-logs) to debug the error. Rails outputs logs in the same terminal where `rails server` was started.
+
+## Specify the Ruby Version
+
+Rails 8 requires Ruby 3.2.0 or above. Heroku installs a recent version of Ruby by default. Specify an exact version with the `ruby` DSL in `Gemfile`. For example:
+
+```ruby
+:::-- $ sed -i'' -e '/^ruby/d' ./Gemfile
+:::-> file.append Gemfile#4
+ruby "3.2.6"
+```
+
+Update the `RUBY VERSION` in the `Gemfile.lock` by running:
+
+```term
+:::>> $ bundle update --ruby
+```
+
+Verify the change:
+
+```term
+:::>> $ cat Gemfile.lock | grep RUBY -a1
+```
+
+Always use the same version of Ruby locally. Confirm the local version of ruby with `ruby -v`. Refer to the [Ruby Versions](ruby-versions) article for more details on defining a specific ruby version.
+
+## Create a Procfile
+
+Use a [Procfile](procfile), a text file in the root directory of your application, to explicitly declare what command to execute to start your app.
+
+This Procfile declares a single process type, `web`, and the command needed to run it.  The name `web` is important here.  It declares that this process type is attached to Heroku's [HTTP routing](http-routing) stack and receives web traffic when deployed.
+
+By default, a Rails app’s web process runs `rails server`, which uses Puma in Rails 8. When you deploy a Rails 8 application without a `Procfile`, this command executes. However, we recommend explicitly declaring how to boot your server process via a `Procfile`. For example:
+
+```
+:::-> file.write Procfile
+web: bundle exec puma -C config/puma.rb
+```
+
+>note
+>The `Procfile` filename is case sensitive. There is no file extension.
+
+If `config/puma.rb` doesn’t exist, create one using [Heroku’s Puma documentation](https://devcenter.heroku.com/articles/deploying-rails-applications-with-the-puma-web-server) for maximum performance.
+
+A Procfile can contain additional process types.  For example, you can declare a [background worker process](background-jobs-queueing#process-model) that processes items off a queue.
+
+## Store The App in Git
+
+Heroku relies on [Git](http://git-scm.com/), a distributed source control management tool, for deploying applications. If the application is not already in Git, first verify that `git` is on the system with `git --help`:
+
+```term
+:::>- $ git --help
+:::>> | $ head -n 5
+```
+
+If the command produces no output or `command not found`, [install Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git).
+
+Navigate to the root directory of the Rails app. Use the `ls` command to see its contents:
+
+```term
+:::>> $ ls
+```
+
+Within the Rails app directly, initialize a local empty Git repository and commit the app’s code:
+
+```term
+:::>- $ git init
+:::>- $ git add .
+:::>- $ git commit -m "init"
+```
+
+Verify everything committed correctly with `git status`:
+
+```term
+:::>> $ git status
+```
+
+With the application committed to Git, it's ready to deploy to Heroku.
+
+## Create a Heroku App
+
+>warning
+>Using a dyno and a database to complete this tutorial counts towards your usage. [Delete your app](https://devcenter.heroku.com/articles/heroku-cli-commands#heroku-apps-destroy), and [database](https://devcenter.heroku.com/articles/heroku-postgresql#removing-the-add-on) as soon as you're done to control costs.
+
+To create an app on Heroku, use the Heroku CLI Inside the Rails app’s root directory:
+
+```term
+:::>> $ heroku apps:create
+```
+
+When you create an app, a git remote called `heroku` is also created and associated with your local git repository. Git remotes are versions of your repository that live on other servers. You deploy your app by pushing its code to that special Heroku-hosted remote associated with your app. Verify the remote is set with `git config`:
+
+```term
+:::>> $ git config --list --local | grep heroku
+```
+
+If the current directory is incorrect or Git isn't [initialized](#store-the-app-in-git), Git returns `fatal: not in a git directory`. If Git returns a list of remotes, it's ready to deploy.
+
+>note
+>Following changes in the industry, Heroku [updated the default branch name](​​https://devcenter.heroku.com/changelog-items/1829) to `main`. If the project uses `master` as its default branch name, use `git push heroku master`.
+
+## Provision a Database
+
+Provision a [Heroku Postgres](https://devcenter.heroku.com/articles/heroku-postgresql) database, one of the add-ons available through the [Elements Marketplace](https://www.heroku.com/elements/addons). Add-ons are cloud services that provide out-of-the-box additional services for your application, such as logging, monitoring, databases, and more.
+
+>note
+>A `mini` Postgres size costs [$5 a month, prorated to the minute](https://elements.heroku.com/addons/heroku-postgresql). At the end of this tutorial, we prompt you to [delete your database](https://devcenter.heroku.com/articles/heroku-postgresql#removing-the-add-on) to minimize costs.
+
+```term
+:::>> $ heroku addons:create heroku-postgresql:essential-0
+```
+
+Your Heroku app can now access this Postgres database. The `DATABASE_URL` environment variable stores your credentials, which Rails connects to by convention.
+
+## Deploy the App to Heroku
+
+>warning
+>Using a dyno to complete this tutorial counts towards your usage. [Delete your app](https://devcenter.heroku.com/articles/heroku-cli-commands#heroku-apps-destroy) as soon as you're done to control costs.
+
+Deploy your code. This command pushes the `main` branch of the sample repo to your `heroku` remote, which then deploys to Heroku:
+
+```term
+:::>> $ git push heroku main
+```
+
+If the output displays warnings or error messages, check the output and make adjustments.
+
+After a successful deployment, complete these tasks as necessary:
+
+* Database migrations
+* Scale your dynos
+* Check the app’s logs if issues arise
+
+## Migrate The Database
+
+If you're using a database in your application, trigger a migration by using the Heroku CLI to start a one-off [dyno](dynos). You can run commands, typically scripts and applications that are part of your app, in one-off dynos using the `heroku run` command. You can trigger a database migration with this command:
+
+```term
+$ heroku run rake db:migrate
+```
+
+To use an interactive shell session instead, you can execute `heroku run bash`.
+
+## Scale and Access the Application
+
+Heroku runs application code using defined processes and [process types](procfile). New applications don't have a process type active by default. The following command scales your app up to one dyno, running the `web` process:
+
+```term
+:::>- $ heroku ps:scale web=1
+```
+
+Use the Heroku CLI’s `ps` command to display the state of all app dynos in the terminal:
+
+```term
+:::>> $ heroku ps
+```
+
+In this example, a single `web` process is running.
+
+By default, apps use Eco dynos if you're subscribed to [Eco](eco-dyno-hours). Otherwise, it defaults to Basic dynos. The Eco dynos plan is shared across all Eco dynos in your account and is recommended if you plan on deploying many small apps to Heroku. Eco dynos sleep if they don't receive any traffic for half an hour.  This sleep behavior causes a few seconds delay for the first request upon waking. Eco dynos consume from a monthly, account-level quota of [eco dyno hours](eco-dyno-hours). As long as you haven't exhausted the quota, your apps can continue to run.
+
+To avoid dyno sleeping, upgrade to a Basic or higher dyno type as described in the [Dyno Types](dyno-types) article. Upgrading to at least Standard dynos also allows you to scale up to multiple dynos per process type.
+
+To launch the app in the browser, run `heroku open`:
+
+```term
+:::>> $ heroku open
+```
+
+The browser displays the “Hello World” text. If it doesn't, or there's an error, [review and confirm the welcome page contents](#create-a-welcome-page).
+
+Heroku provides a [default web URL](app-names-and-subdomains) for every application during development. When the application is ready for production, add a [custom domain](https://devcenter.heroku.com/articles/custom-domains).
+
+## View Application Logs
+
+The app logs are a valuable tool if the app is not performing correctly or generating errors.
+
+View information about a running app using the Heroku CLI [logging command](logging), `heroku logs`. Here's example output:
+
+```term
+:::>> $ heroku logs
+```
+
+Append `-t`/`--tail` to the command to see a full, live stream of the app’s logs:
+
+```term
+$ heroku logs --tail
+```
+
+By default, Heroku stores 1500 lines of logs from your application, but the full log stream is available as a service. Several [add-on providers](https://elements.heroku.com/addons/#logging) have logging services that provide things such as log persistence, search, and email and SMS alerts.
+
+## Optional Steps
+
+### Use The Rails Console
+
+Use the Heroku CLI `run` command to trigger [one-off dynos](one-off-dynos) to run scripts and applications only when necessary. Use the command to launch a Rails console process attached to the local terminal for experimenting in the app's environment:
+
+```term
+$ heroku run rails console
+irb(main):001:0> puts 1+1
+2
+```
+
+The `run bash` Heroku CLI command is also helpful for debugging. The command starts a new one-off dyno with an interactive bash session.
+
+### Run Rake Commands
+
+Run `rake` commands, such as `db:migrate`, using the `run` command exactly like the Rails console:
+
+```term
+$ heroku run rake db:migrate
+```
+
+### Use a Procfile locally
+
+To use the `Procfile` locally, use the `heroku local` CLI command.
+
+In addition to running commands in the `Procfile`, the `heroku local` command can also manage environment variables locally through a `.env` file. Set `RACK_ENV` to `development` for the local environment and the `PORT` for Puma.
+
+```term
+:::>> $ echo "RACK_ENV=development" >>.env
+:::>> $ echo "PORT=3000" >> .env
+```
+
+>note
+> Another alternative to using environment variables locally with a `.env` file is the [dotenv](https://github.com/bkeepers/dotenv) gem.
+
+Add `.env` to `.gitignore` as these variables are for local environment setup only.
+
+```term
+:::>- $ echo ".env" >> .gitignore
+:::>- $ git add .gitignore
+:::>- $ git commit -m "add .env to .gitignore"
+```
+
+Test the Procfile locally using [Foreman](heroku-local#run-your-app-locally-using-foreman)​​. Start the web server with `local`:
+
+```term
+:::>> background.start("heroku local", name: "local", wait: "Ctrl-C to stop", timeout: 15)
+:::-- background.stop(name: "local")
+```
+
+Press `Ctrl+C` or `Cmd+C` to exit.
+
+## Troubleshooting
+
+If an app deployed to Heroku crashes, for example, `heroku ps` shows the state `crashed`, review the app’s logs. The following section covers common causes of app crashes.
+
+### Runtime Dependencies on Development or Test Gems
+
+If a gem is missing during deployment, check the Bundler groups. Heroku builds apps without the `development` or `test` groups, and if the app depends on a gem from one of these groups to run, move it out of the group.
+
+A common example is using the RSpec tasks in the `Rakefile`. The error often looks like this:
+
+```term
+$ heroku run rake -T
+Running `bundle exec rake -T` attached to terminal... up, ps.3
+rake aborted!
+no such file to load -- rspec/core/rake_task
+```
+First, duplicate the problem locally by running `bundle install` without the development or test gem groups:
+
+```term
+$ bundle install --without development:test
+…
+$ bundle exec rake -T
+rake aborted!
+no such file to load -- rspec/core/rake_task
+```
+
+>note
+>The `--without` option on `bundler` is persistent. To remove this option, run `bundle config --delete without`.
+
+Fix the error by making these Rake tasks conditional during gem load. For example:
+
+```ruby
+begin
+  require "rspec/core/rake_task"
+
+  desc "Run all examples"
+
+  RSpec::Core::RakeTask.new(:spec) do |t|
+    t.rspec_opts = %w[--color]
+    t.pattern = 'spec/**/*_spec.rb'
+  end
+rescue LoadError
+end
+```
+
+Confirm it works locally, then push it to Heroku.
+
+## Next Steps
+
+Congratulations on deploying a Rails 8 application! To continue exploring, review the following articles next:
+
+* Visit the [Ruby support category](/categories/ruby-support) to learn more about using Ruby and Rails on Heroku.
+* The [Deployment category](/categories/deployment) provides a variety of powerful integrations and features to help streamline and simplify your deployments.
+
+>note
+>Remember to [delete your example app](https://devcenter.heroku.com/articles/heroku-cli-commands#heroku-apps-destroy), and [database](https://devcenter.heroku.com/articles/heroku-postgresql#removing-the-add-on) as soon as you're done with the tutorial, to control costs.
+
+## Delete Your App and Add-on
+
+Remove the app and database from your account. You're only charged for the resources you used.
+
+>warning
+>This action removes your add-on and any data saved in the database.
+
+```term
+$ heroku addons:destroy heroku-postgresql
+```
+
+>warning
+>This action permanently deletes your application
+
+```term
+$ heroku apps:destroy
+```
+
+You can confirm that your add-on and app are gone with these commands:
+
+```term
+$ heroku addons --all
+$ heroku apps --all
+```
+
+You're now ready to <a href= "https://devcenter.heroku.com/articles/preparing-a-codebase-for-heroku-deployment" target= "_blank">deploy your app</a>.

data/test/fixtures/simple_git/rundoc.md

@@ -0,0 +1,13 @@
+```
+:::-- $ git config --get user.email || git config --global user.email "developer@example.com"
+:::-- $ git config --get user.name || git config --global user.name "Developer name"
+```
+
+```
+:::>> $ echo "hello world" >> lol.txt
+:::>> $ git init .
+:::>> $ git add .
+:::>> $ git commit -m first
+:::>> $ echo "so long and thanks for all the fish" >> lol.txt
+:::>> $ git add . && git commit -m second
+```