Skip to content

feat: Update Hugo and PR template guidance #894

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
43 changes: 18 additions & 25 deletions .github/pull_request_template.md
Original file line number Diff line number Diff line change
@@ -1,35 +1,28 @@
### Proposed changes

Write a clear and concise description that helps reviewers understand the purpose and impact of your changes. Use the
following format:
[//]: # "Write a clear and concise description of what the pull request changes."
[//]: # "You can use our Commit messages guidance for this."
[//]: # "https://github.com/nginx/documentation/blob/main/documentation/git-conventions.md#commit-messages"

Problem: Give a brief overview of the problem or feature being addressed.
[//]: # "First, explain what was changed, and why. This should be most of the detail."
[//]: # "Then how the changes were made, such as referring to existing styles and conventions."
[//]: # "Finish by noting anything beyond the scope of the PR changes that may be affected."

Solution: Explain the approach you took to implement the solution, highlighting any significant design decisions or
considerations.
[//]: # "Include information on testing if relevant and non-obvious from the deployment preview."
[//]: # "For expediency, you can use screenshots to show small before and after examples."

Testing: Describe any testing that you did.

Please focus on (optional): If you any specific areas where you would like reviewers to focus their attention or provide
specific feedback, add them here.

If this PR addresses an [issue](https://github.com/nginx/documentation/issues) on GitHub, ensure that you link to it here:

Closes #ISSUE
[//]: # "If the changes were defined by a GitHub issue, reference it using keywords."
[//]: # "https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/using-keywords-in-issues-and-pull-requests"
[//]: # "DO NOT LINK TO ANY INTERNAL, NON-PUBLIC RESOURCES. THIS INCLUDES BOTH INTERNAL REPOSITORY ISSUES OR ANYTHING IN AN INTRANET."
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure this is necessary. I think it's understood that even open source companies -- with a public roadmap -- have internal discussions. While at other open source companies, I've marked links as "internal"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've been trying to minimize my use of internal links. I can say that it's at best "inconvenient". IMO, it adds confusion to discussions with stakeholders.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I get why this feels unnecessary, but it's also reinforcing the mentality that a commit description should contain all of the context required to understand the set of changes it contains.

Imagine you have checked out the repository, and have no way of learning anything except for what is visible to you in git history. No access to communication channels or any internal documentation.

Giving an internal resource as context for changes is efficient for time but not effective for communication. I solve this for my work by adding or extrapolating relevant details into a public-facing issue or as part of the commit description.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I therefore suggest:

Suggested change
[//]: # "DO NOT LINK TO ANY INTERNAL, NON-PUBLIC RESOURCES. THIS INCLUDES BOTH INTERNAL REPOSITORY ISSUES OR ANYTHING IN AN INTRANET."
[//]: # "Mark any link to internal, non-public resources as INTERNAL"

Copy link
Contributor

@mjang mjang Jul 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or, based on an INTERNAL discussion:

Suggested change
[//]: # "DO NOT LINK TO ANY INTERNAL, NON-PUBLIC RESOURCES. THIS INCLUDES BOTH INTERNAL REPOSITORY ISSUES OR ANYTHING IN AN INTRANET."
[//]: # SECURITY ISSUE: Do NOT add links to internal, non-public resources. This includes both internal repository issues or anything in the F5 intranet. However, it is OK to refer to internal discussions, without links.".

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Giving an internal resource as context for changes is efficient for time but not effective for communication. I solve this for my work by adding or extrapolating relevant details into a public-facing issue or as part of the commit description.

I hear you, but that can lead to two "sources of truth" for discussions. Almost by definition, it's at best difficult to make the same points publicly and privately.

Copy link
Contributor

@mjang mjang Jul 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternative thought:

  • Suggest that internal authors create issues / PRs in the internal repositories, where they can (safely) link to internal discussions

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hear you, but that can lead to two "sources of truth" for discussions. Almost by definition, it's at best difficult to make the same points publicly and privately.

To an extent, the only real source of truth is what the thing actually does, not what anyone claims or thinks it should, but beyond philosophical pedantry, I treat issues as the source of truth and the git codebase as the enactment of any changes specified by them.

That's part of the definition of done for acceptance criteria and reviews: that the work accurately reflects the intent. If the issue is not a source of truth, then there was not sufficient research or information was captured erroneously.

I think the proposed security-leaning suggestion is needlessly elongating the directive by justifying it: the original change simply says not to link any internal resources. It does not specify you cannot refer to them.

Explicitly listing everything you can or cannot or should or should not do is precisely how the Checklist became long enough in the first place to warrant change: it's noise.

Copy link
Contributor

@mjang mjang Jul 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given the context, I'm continuing discussion internally

(I don't know how to respond without revealing internal information.)


### Checklist

Before merging a pull request, run through this checklist and mark each as complete.
Before sharing this pull request, I completed the following checklist:

- [ ] I have read the [contributing guidelines](https://github.com/nginx/documentation/blob/main/CONTRIBUTING.md)
- [ ] I have signed the [F5 Contributor License Agreement (CLA)](https://github.com/f5/.github/blob/main/CLA/cla-markdown.md)
- [ ] I have rebased my branch onto main
- [ ] I have ensured my PR is targeting the main branch and pulling from my branch from my own fork
- [ ] I have ensured that the commit messages adhere to [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/#summary)
- [ ] I have ensured that documentation content adheres to [the style guide](/documentation/style-guide.md)
- [ ] If the change involves potentially sensitive changes[^1], I have assessed the possible impact
- [ ] If applicable, I have added tests that prove my fix is effective or that my feature works
- [ ] I have ensured that existing tests pass after adding my changes
- [ ] If applicable, I have updated [`README.md`](/README.md)
- [ ] I read the [Contributing guidelines](/CONTRIBUTING.md)
- [ ] My branch adheres to the [Git conventions](/documentation/git-conventions.md)
- [ ] My content changes adhere to the [F5 NGINX Documentation style guide](/documentation/style-guide.md)
- [ ] If my changes involve potentially sensitive information[^1], I have assessed the possible impact
- [ ] I have waited to ensure my changes pass tests, and addressed any discovered issues

[^1]: Potentially sensitive changes include anything involving code, personally identify information (PII), live URLs or significant amounts of new or revised documentation. Please refer to [our style guide](/documentation/style-guide.md) for guidance about placeholder content.
[^1]: Potentially sensitive information includes personally identify information (PII), authentication credentials, and live URLs. Refer to the [style guide](/documentation/style-guide.md) for guidance about placeholder content.
83 changes: 38 additions & 45 deletions documentation/writing-hugo.md
Original file line number Diff line number Diff line change
Expand Up @@ -87,53 +87,58 @@ To install <integation>, refer to the [integration instructions]({{< ref "/integ

### How to use Hugo shortcodes

[Hugo shortcodes](https://github.com/nginxinc/nginx-hugo-theme/tree/main/layouts/shortcodes) are used to format callouts, add images, and reuse content across different pages.
[Hugo shortcodes](https://github.com/nginxinc/nginx-hugo-theme/tree/main/layouts/shortcodes) are used to provide extra functionality and special formatting to Markdown content.

For example, to use the `note` callout:
This is an example of a call-out shortcode:

```md
{{< note >}} Provide the text of the note here .{{< /note >}}
{{< call-out "note" >}} Provide the text of the note here .{{< /call-out >}}
```

The callout shortcodes support multi-line blocks:
Here are some other shortcodes:

- `include`: Include the content of a file in another file: read the [Re-use content with includes](#re-use-content-with-includes) instructions
- `tabs`: Create mutually exclusive tabbed window panes, useful for parallel instructions
- `table`: Add scrollbars to wide tables for browsers with smaller viewports
- `icon`: Add a [Lucide icon](https://lucide.dev/icons/) by using its name as a parameter
- `link`: Link to a file, prepending its path with the Hugo baseUrl
- `ghcode`: Embeds the contents of a code file: read the [Add code to documentation pages](#add-code-to-documentation-pages) instructions
- `openapi`: Loads an OpenAPI specification and render it as HTML using ReDoc

#### Add call-outs to documentation pages

The call out shortcode support multi-line blocks:

```md
{{< caution >}}
{{< call-out "caution" >}}
You should probably never do this specific thing in a production environment.

If you do, and things break, don't say we didn't warn you.
{{< /caution >}}
{{< /call-out >}}
```

Supported callouts:
The first parameter determines the type of call-out, which defines the colour given to it.

Supported types:
- `note`
- `tip`
- `important`
- `caution`
- `warning`

You can also create custom callouts using the `call-out` shortcode `{{< call-out "type position" "header" "font-awesome icon >}}`. For example:
An optional second parameter will add a title to the call-out: without it, it will fall back to the type.

```md
{{<call-out "important side-callout" "JWT file required for upgrade" "fa fa-exclamation-triangle">}}
```
{{< call-out "important" "This instruction only applies to v#.#.#" >}}
These instructions are only intended for versions #.#.# onwards.

By default, all custom callouts are displayed inline, unless you add `side-callout` which places the callout to the right of the content.

Here are some other shortcodes:
Follow <these-instructions> if you're using an older version.
{{< /call-out >}}
```

- `fa`: Inserts a Font Awesome icon
- `collapse`: Make a section collapsible
- `tab`: Create mutually exclusive tabbed window panes, useful for parallel instructions
- `table`: Add scrollbars to wide tables for browsers with smaller viewports
- `link`: Link to a file, prepending its path with the Hugo baseUrl
- `openapi`: Loads an OpenAPI specification and render it as HTML using ReDoc
- `include`: Include the content of a file in another file; the included file must be present in the '/content/includes/' directory
- `raw-html`: Include a block of raw HTML
- `readfile`: Include the content of another file in the current file, which can be in an arbitrary location.
- `bootstrap-table`: formats a table using Bootstrap classes; accepts any bootstrap table classes as additional arguments, e.g. `{{< bootstrap-table "table-bordered table-hover" }}`
Finally, you can use an optional third parameter to add a [Lucide icon](https://lucide.dev/icons/) using its name.

### Add code to documentation pages
#### Add code to documentation pages

For command, binary, and process names, we sparingly use pairs of backticks (\`\<some-name\>\`): `<some-name>`.

Expand All @@ -145,22 +150,9 @@ You can also use the `ghcode` shortcode to embed a single file directly from Git

An example of this can be seen in [/content/ngf/get-started.md](https://github.com/nginx/documentation/blob/af8a62b15f86a7b7be7944b7a79f44fd5e526c15/content/ngf/get-started.md?plain=1#L233C1-L233C128), which embeds a YAML file.

#### Re-use content with includes

### Add images to documentation pages

Use the `img` shortcode to add images to documentation pages. It has the same parameters as the Hugo [figure shortcode](https://gohugo.io/content-management/shortcodes/#figure).

1. Add the image to the `/static/img` directory.
2. Add the `img` shortcode:
- `{{< img src="<img-file.png>" alt="<Alternative text>">}}`
- Do not include a forward slash at the beginning of the file path or it will [break the image](https://gohugo.io/functions/relurl/#input-begins-with-a-slash).

> **Important**: We have strict guidelines for using images. Review them in our [style guide](/documentation/style-guide.md#guidelines-for-screenshots).


### How to use Hugo includes

Hugo includes are a custom shortcode that allows you to embed content stored in the [`/content/includes` directory](https://github.com/nginx/documentation/tree/main/content/includes).
The includes are a custom shortcode that allows you to embed content stored in the [`/content/includes` directory](https://github.com/nginx/documentation/tree/main/content/includes).

It allows for content to be defined once and display in multiple places without duplication, creating consistency and simplifying the maintenance of items such as reference tables.

Expand All @@ -180,12 +172,13 @@ This particular include file is used in the following pages:

View the [Guidelines for includes](/templates/style-guide.md#guidelines-for-includes) for instructions on how to write effective include files.

## Linting
#### Add images to documentation pages

To use markdownlint to check content, run the following command:
Use the `img` shortcode to add images to documentation pages. It has the same parameters as the Hugo [figure shortcode](https://gohugo.io/content-management/shortcodes/#figure).

```shell
markdownlint -c .markdownlint.yaml </content/path>
```
1. Add the image to the `/static/img` directory.
2. Add the `img` shortcode:
- `{{< img src="<img-file.png>" alt="<Alternative text>">}}`
- Do not include a forward slash at the beginning of the file path or it will [break the image](https://gohugo.io/functions/relurl/#input-begins-with-a-slash).

The content path can be an individual file or a folder.
> **Important**: We have strict guidelines for using images. Review them in our [style guide](/documentation/style-guide.md#guidelines-for-screenshots).