From 155e0c96742d35de0e38e35b713289d43a389b70 Mon Sep 17 00:00:00 2001
From: Corey Butler <corey@coreybutler.com>
Date: Sat, 4 Apr 2020 12:42:31 -0500
Subject: [PATCH] README formatting updates

---
 README.md | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/README.md b/README.md
index 8957365..93d642d 100644
--- a/README.md
+++ b/README.md
@@ -60,11 +60,11 @@ The `GITHUB_TOKEN` **must** be provided. Without this, it is not possible to cre
 
 The action will automatically extract the token at runtime. **DO NOT MANUALLY ENTER YOUR TOKEN.** If you put the actual token in your workflow file, you'll make it accessible (in plaintext) to anyone who ever views the repository (it will be in your git history).
 
-### Optional Configurations
+## Optional Configurations
 
 There are several options to customize how the tag is created.
 
-#### strategy (required)
+### strategy (required)
 
 This is the strategy used to identify the version number/tag from within the code base.
 
@@ -81,7 +81,7 @@ This is the strategy used to identify the version number/tag from within the cod
     strategy: docker
 ```
 
-#### root
+### root
 _Formerly `package_root`_
 
 Depending on the selected strategy, autotagger will look for the `package.json` or `Dockerfile` file in the project root. If the file is located in a subdirectory, this option can be used to point to the correct file.
@@ -123,7 +123,7 @@ _Using the **regex** strategy:_
 
 The version will be extracted by scanning the content of `/path/to/subdirectory/my.file` for a string like `version=1.0.0`. See the `regex_pattern` option for more details.
 
-#### tag_prefix
+### tag_prefix
 
 By default, [semantic versioning](https://semver.org/) is used, such as `1.0.0`. A prefix can be used to add text before the tag name. For example, if `tag_prefix` is set to `v`, then the tag would be labeled as `v1.0.0`.
 
@@ -134,7 +134,7 @@ By default, [semantic versioning](https://semver.org/) is used, such as `1.0.0`.
     tag_prefix: "v"
 ```
 
-#### tag_suffix
+### tag_suffix
 
 Text can be applied to the end of the tag by setting `tag_suffix`. For example, if `tag_suffix` is ` (beta)`, the tag would be `1.0.0 (beta)`. Please note this example violates semantic versioning and is merely here to illustrate how to add text to the end of a tag name if you _really_ want to.
 
@@ -145,7 +145,7 @@ Text can be applied to the end of the tag by setting `tag_suffix`. For example,
     tag_suffix: " (beta)"
 ```
 
-#### tag_message
+### tag_message
 
 This is the annotated commit message associated with the tag. By default, a changelog will be generated from the commits between the latest tag and the current reference (HEAD). Setting this option will override the message.
 
@@ -156,7 +156,7 @@ This is the annotated commit message associated with the tag. By default, a chan
     tag_message: "Custom message goes here."
 ```
 
-#### commit_message_template
+### commit_message_template
 
 By default, a changelog is generated, containing the commit messages since the last release. The message is generated by applying a commit message template to each commit's data attributes.
 
@@ -186,7 +186,7 @@ _Example output:_
 (SHA: b690be366a5636d51b1245a1b39c86102ddb8a81)
 ```
 
-#### version
+### version
 
 Explicitly set the version instead of using automatic detection.
 
@@ -199,7 +199,7 @@ Useful for projects where the version number may be output by a previous action.
     version: "${{ steps.previous_step.outputs.version }}"
 ```
 
-#### regex_pattern
+### regex_pattern
 
 An optional attribute containing the regular expression used to extract the version number.