fix additional no trailing newlines

content/contributing/syntax-and-versioning-for-github-docs/configuring-redirects.md

@@ -34,7 +34,7 @@ See [`redirect_from`](https://github.com/github/docs/blob/main/content/README.md
 
 If a URL for a page is entered without a version (`https://docs.github.com/ARTICLE` instead of `https://docs.github.com/VERSION/ARTICLE`), the site will automatically redirect it to the first available version of the page.
 
-The order of precedence is specified in [`lib/all-versions.js`](https://github.com/github/docs/blob/main/lib/all-versions.js). The current order of precedence is:
+The order of precedence is specified in [`lib/all-versions.js`](https://github.com/github/docs/blob/main/src/versions/lib/all-versions.js). The current order of precedence is:
 
 1. {% data variables.product.prodname_free_team %}, {% data variables.product.prodname_pro %}, or {% data variables.product.prodname_team %} (`fpt`)
 1. {% data variables.product.prodname_ghe_cloud %} (`ghec`)

content/contributing/syntax-and-versioning-for-github-docs/creating-tool-switchers-in-articles.md

@@ -18,16 +18,19 @@ For tasks that can be completed with different tools, the tool switcher signals
 When someone knows how they want to do a task and doesn’t need to see additional options, the tool switcher removes less relevant content, so they can find exactly what they need.
 
 ## Using tool tags
+
 We use tool tags to divide information for each tool. On rare occasions, we will add new tools.
 
 Tool tags are a key value pair. The key is the tag you use to refer to the tool in the article and the value is how the tool will be identified on the tool picker at the top of the article. The existing tools are in [`lib/all-tools.js`](https://github.com/github/docs/blob/main/src/tools/lib/all-tools.js) in the {% data variables.product.prodname_docs %} repository.
 
 ### When to use tool tags
+
 We only use tool tags if an article must have tool-specific information to help people accomplish their tasks. If the conceptual information or procedural steps for a task are significantly different depending on what tool someone uses, and we want people to be able to accomplish the task with different tools, we use tool tags to present the relevant information in an article.
 
 Do not use the tool switcher just to show examples in different languages. Only use the tool switcher if the tasks or concepts described in an article change based on what tool someone uses.
 
 ### How to use tool tags
+
 Tool tags are Liquid tags that wrap content specific to a tool. <!--For more information on using tool tags in an article, see [AUTOTITLE](/contributing/using-markdown-and-liquid-in-github-docs#tool-tags)."-->
 
 Put tools in alphabetical order. By default, the first tool tag will be selected for an article. You can define a different default tool for an article by specifying a `defaultTool:` property in the article's frontmatter. For more information, see the [content README](https://github.com/github/docs/blob/main/content/README.md#defaulttool).
@@ -37,6 +40,7 @@ You can also link to an article with a specific tool selected by adding `?tool=T
 Only include a maximum of eight different tools in an article. Including more tools causes the tool switcher tabs to overflow with an article's table of contents, which prevents people from using either the tool switcher or table of contents. It is unlikely that you will ever need to include eight separate tools in an article. In general, plan to use as few separate tools as possible in an article.
 
 ## Adding new tools
+
 If a writer determines that adding a new tool is the only way to accurately document something, they should explain their reasoning in the content planning stage. Whoever reviews content plan should consider if there are any alternative ways to address the documentation need without adding a new tool. If a new tool is the only way to create accurate documentation, the new tool should be added. If there is an alternative content solution that does not add a new tool, that option should be used.
 
 To add a new tool, add an entry to the `allTools` object in the [`lib/all-tools.js`](https://github.com/github/docs/blob/main/src/tools/lib/all-tools.js) file as a key-value pair. Add new tools in alphabetical order.

content/contributing/syntax-and-versioning-for-github-docs/using-markdown-and-liquid-in-github-docs.md

@@ -102,6 +102,7 @@ const copyMe = true
 ```
 
 ## Code sample annotations
+
 Code sample annotations help explain longer code examples by rendering comments as annotations next to the sample code. This lets us write longer explanations of code without cluttering the code itself. Code samples with annotations are rendered in a two pane layout with the code sample on the left and the annotations on the right. The annotations are visually emphasized when someone hovers their cursor over the code example.
 
 Code annotations only work in articles with the `layout: inline` frontmatter property. For more information on how to write and style code annotations, see "[AUTOTITLE](/contributing/syntax-and-versioning-for-github-docs/annotating-code-examples)."
@@ -357,14 +358,19 @@ For example, if you include the following link in a content file:
 ```
 /github/writing-on-github/creating-a-saved-reply
 ```
+
 When viewed on {% data variables.product.prodname_dotcom_the_website %} docs, the link gets rendered with the language code:
+
 ```
 /en/github/writing-on-github/creating-a-saved-reply
 ```
+
 and when viewed on {% data variables.product.prodname_ghe_server %} docs, the version is included as well:
+
 ```
 /en/enterprise-server@2.20/github/writing-on-github/creating-a-saved-reply
 ```
+
 For more information about links, see "[AUTOTITLE](/contributing/writing-for-github-docs/style-guide#links)."
 
 ### Permalinks

content/contributing/syntax-and-versioning-for-github-docs/using-yaml-frontmatter.md

@@ -43,7 +43,7 @@ For more information, see [`lib/frontmatter.js`](https://github.com/github/docs/
 
 ### `versions`
 
-- Purpose: Indicates the [versions](https://github.com/github/docs/blob/main/lib/all-versions.js) to which a page applies.
+- Purpose: Indicates the [versions](https://github.com/github/docs/blob/main/src/versions/lib/all-versions.js) to which a page applies.
 For more information about the different types of versioning, see "[Versioning documentation](/contributing/syntax-and-versioning-for-github-docs/versioning-documentation)."
 - Type: `Object`. Allowable keys map to product names and can be found in the `versions` object in [`lib/frontmatter.js`](https://github.com/github/docs/blob/main/lib/frontmatter.js).
 - This frontmatter value is currently **required** for all pages.
@@ -221,6 +221,7 @@ defaultTool: cli
 ```
 
 ### `learningTracks`
+
 - Purpose: Render a list of learning tracks on a product's sub-landing page.
 - type: `String`. This should reference learning tracks' names defined in [`data/learning-tracks/*.yml`](https://github.com/github/docs/tree/main/data/learning-tracks).
 - Optional
@@ -232,6 +233,7 @@ defaultTool: cli
 {% endnote %}
 
 ### `includeGuides`
+
 - Purpose: Render a list of articles, filterable by `type` and `topics`. Only applicable when used with `layout: product-guides`.
 - Type: `Array`
 - Optional.
@@ -247,21 +249,25 @@ includeGuides:
 ```
 
 ### `type`
+
 - Purpose: Indicate the type of article.
 - Type: `String`, one of the `overview`, `quick_start`, `tutorial`, `how_to`, `reference`.
 - Optional.
 
 ### `topics`
+
 - Purpose: Indicate the topics covered by the article. The topics are used to filter guides on some landing pages. For example, the guides at the bottom of "[Guides for {% data variables.product.prodname_actions %}](/actions/guides#all-guides)" can be filtered by topics, and the topics are listed under the guide intro. Refer to the content models for more details about adding topics. A full list of  existing topics is located in the [allowed topics file](https://github.com/github/docs/blob/main/data/allowed-topics.js). If topics in article frontmatter and the allow-topics list become out of sync, the [topics CI test](https://github.com/github/docs/blob/main/src/search/tests/topics.js) will fail.
 - Type: Array of `String`s
 - Optional: Topics are preferred for each article, but, there may be cases where existing articles don't yet have topics, or adding a topic to a new article may not add value.
 
 ### `communityRedirect`
+
 - Purpose: Set a custom link and link name for `Ask the GitHub community` link in the footer.
 - Type: `Object`. Properties are `name` and `href`.
 - Optional.
 
 ### `effectiveDate`
+
 - Purpose: Set an effective date for Terms of Service articles so that engineering teams can automatically re-prompt users to confirm the terms
 - Type: `string` YEAR-MONTH-DAY e.g. 2021-10-04 is October 4th, 2021
 - Optional.

content/contributing/syntax-and-versioning-for-github-docs/versioning-documentation.md

@@ -65,7 +65,7 @@ For {% data variables.product.prodname_ghe_cloud %}, use `enterprise-cloud@lates
 
 ### {% data variables.product.prodname_ghe_server %}
 
-Documentation for {% data variables.product.prodname_ghe_server %} has multiple versions and can be divided into two types: documentation for _supported releases_ (we support four at any one time), and documentation for _deprecated releases_ (we do not link to these on the Docs site but we support a "frozen" snapshot of these docs in perpetuity, so they can still be accessed if you know the URLs). See [`lib/enterprise-server-releases.js`](https://github.com/github/docs/blob/main/lib/enterprise-server-releases.js) for a list.
+Documentation for {% data variables.product.prodname_ghe_server %} has multiple versions and can be divided into two types: documentation for _supported releases_ (we support four at any one time), and documentation for _deprecated releases_ (we do not link to these on the Docs site but we support a "frozen" snapshot of these docs in perpetuity, so they can still be accessed if you know the URLs). See [`lib/enterprise-server-releases.js`](https://github.com/github/docs/blob/main/src/versions/lib/enterprise-server-releases.js) for a list.
 
 The versions are named `enterprise-server@<release>`. The short name is `ghes`. In Liquid conditionals, we can specify ranges, like `ghes > 3.0`. For more information, see "[Versioning with Liquid conditional operators](#versioning-with-liquid-conditional-operators)."
 
@@ -259,7 +259,7 @@ You can version documentation to appear in the current {% data variables.product
 
 ### About the displayed version of {% data variables.product.prodname_ghe_managed %} documentation
 
-We display one version of {% data variables.product.prodname_ghe_managed %} documentation on {% data variables.product.prodname_docs %}: the latest.  We define "latest" in the site's source, within [`all-versions.js`](https://github.com/github/docs/blob/main/lib/all-versions.js#L58). In almost all cases, this value is a safe place to determine the latest public release of {% data variables.product.prodname_ghe_managed %}.
+We display one version of {% data variables.product.prodname_ghe_managed %} documentation on {% data variables.product.prodname_docs %}: the latest.  We define "latest" in the site's source, within [`all-versions.js`](https://github.com/github/docs/blob/main/src/versions/lib/all-versions.js#L58). In almost all cases, this value is a safe place to determine the latest public release of {% data variables.product.prodname_ghe_managed %}.
 
 "Latest" corresponds with the latest version of {% data variables.product.prodname_ghe_managed %} that we've deployed to the first customer using the product in production. Generally, {% data variables.product.company_short %} upgrades all production customers on {% data variables.product.prodname_ghe_managed %} to the latest version around the same time, so Product considers only showing the latest documentation an acceptable compromise.