website: bump prettier from 3.5.3 to 3.6.0 in /website (#15199)
* website: bump prettier from 3.5.3 to 3.6.0 in /website Bumps [prettier](https://github.com/prettier/prettier) from 3.5.3 to 3.6.0. - [Release notes](https://github.com/prettier/prettier/releases) - [Changelog](https://github.com/prettier/prettier/blob/main/CHANGELOG.md) - [Commits](https://github.com/prettier/prettier/compare/3.5.3...3.6.0) --- updated-dependencies: - dependency-name: prettier dependency-version: 3.6.0 dependency-type: direct:development update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> * format Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: dependabot[bot] <support@github.com> Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Jens Langhammer <jens@goauthentik.io>
This commit is contained in:
dependabot[bot]
@ -127,7 +127,6 @@ Whether to capitalize after a colon depends on the context. Typically, we do not
|
||||
|
||||
- Typically, avoid using the word "may" in technical writing, as it implies permission rather than ability to perform an action. Instead, use **"can"** to suggest possibility.
|
||||
- **"Might"** should be used to indicate that something could happen under certain conditions, but use it sparingly. It implies unpredictability, which can be undesirable in software documentation.
|
||||
|
||||
- **DON'T:** "You may use an Expression policy to enforce MFA adherence."
|
||||
- **DO:** "You can use an Expression policy to enforce MFA adherence."
|
||||
- **DO:** "Values might differ depending on the source of the property mappings."
|
||||
@ -172,16 +171,13 @@ When writing out steps in a procedural topic, avoid starting with "Once...". Ins
|
||||
- When referring to authentik functionality and features, such as flows, stages, sources, or policies, do not capitalize and do not use bold or italic text. When possible link to the corresponding documentation.
|
||||
|
||||
- Use **bold** to highlight:
|
||||
|
||||
- UI elements such as field names, labels, buttons, or options (e.g., **Save** button, **Username** field).
|
||||
- Key actions in instructions (e.g., **Click Next**).
|
||||
|
||||
- Use _italic_ for:
|
||||
|
||||
- Emphasis, but sparingly, to avoid overuse. For example, you can use italics for important terms or concepts on first mention in a section. Do not use italics to indicate a variable or placeholder; instead use angle brackets as described under [Variables](#variables).
|
||||
|
||||
- Use `code formatting` for:
|
||||
|
||||
- Commands (e.g., `kubectl get nodes`).
|
||||
- File paths, file names, and directory names (e.g., `/usr/local/bin/`).
|
||||
- Inline code snippets (e.g., `.env`).
|
||||
@ -211,7 +207,6 @@ To clearly indicate terms or values that are placeholders and require user input
|
||||
### Titles and headers
|
||||
|
||||
- Titles and headers (H1, H2, H3) should follow **sentence case capitalization**, meaning only the first word is capitalized, except for proper nouns or product names.
|
||||
|
||||
- **DO:** "Configure the Google Workspace provider"
|
||||
- **DON'T:** "CONFIGURE THE GOOGLE WORKSPACE PROVIDER"
|
||||
- **DON'T:** "Configure The Google Workspace Provider"
|
||||
@ -332,7 +327,6 @@ When documenting errors, follow this structure:
|
||||
```
|
||||
|
||||
- **Possible causes**:
|
||||
|
||||
- Incorrect username or password.
|
||||
- Account locked due to multiple failed attempts.
|
||||
|
||||
@ -422,7 +416,6 @@ This level is for extremely serious situations, such as an action permanently re
|
||||
Note: Badges should be defined in the front matter, not in the markdown content. The system will automatically display the appropriate badges based on the front matter metadata.
|
||||
|
||||
- **Directives**: You can also use directives in your markdown content to add badges inline:
|
||||
|
||||
- `:ak-version[2025.4]` - Shows when a feature was introduced (requires semantic version)
|
||||
- `:ak-preview` - Indicates preview features
|
||||
- `:ak-enterprise` - Indicates features in our Enterprise offering
|
||||
|
||||
@ -13,7 +13,6 @@
|
||||
- Create/update the release notes
|
||||
|
||||
#### For initial releases:
|
||||
|
||||
- Copy `website/docs/releases/_template.md` to `website/docs/releases/v2022.12.md` and replace `xxxx.x` with the version that is being released
|
||||
|
||||
- Fill in the section of `Breaking changes` and `New features`, or remove the headers if there's nothing applicable
|
||||
@ -35,7 +34,6 @@
|
||||
- Run `make website`
|
||||
|
||||
#### For subsequent releases:
|
||||
|
||||
- Paste the list of commits since the previous release into `website/docs/releases/v2022.12.md`, creating a new section called `## Fixed in 2022.12.2` underneath the `Minor changes/fixes` section
|
||||
|
||||
- Run `make gen-changelog` and use the contents of `changelog.md`. Remove merged PRs from bumped dependencies unless they fix security issues or are otherwise notable. Remove merged PRs with the `website/` prefix.
|
||||
@ -48,7 +46,6 @@
|
||||
- Push the tag and commit
|
||||
- A GitHub actions workflow will start to run a last test in container images and create a draft release on GitHub
|
||||
- Edit the draft GitHub release
|
||||
|
||||
- Make sure the title is formatted `Release 2022.12.0`
|
||||
- Add the following to the release notes
|
||||
|
||||
|
||||
Reference in New Issue
Block a user