Source proxy and Edge docs from GitHub (#3122)
## What
The main purpose of this PR is to
1. Delete the proxy docs in this repo and replace them with the proxy's
GitHub readme.
2. Add the docs for Unleash Edge.
### Detailed change description
This PR contains a lot of small changes in a large number of files. To
make it easier to get an overview, here's a detailed description of what
happens where:
#### In the `website/docs`directory
Except for the deletion of the proxy doc, all changes in this directory
are rewriting internal links, so that they point to the newly generated
document instead.
#### `package.json` and `yarn.lock`
When including the documentation for Edge, we also want to render the
mermaid diagrams it uses. Docusaurus supports this via a plugin. All
changes in these files are related to installing that plugin.
#### `docusaurus.config.js`
There's two types of changes in this file:
1. Mermaid-related changes: we ask docusaurus to render mermaid in
markdown files and add the plugin
2. Document generation. There's some rewrites to the sdk doc generation
plus an entirely new section that generates docs for Edge and the proxy
#### `sidebars.js`
Two things:
1. Add the edge docs
2. Move both the Edge and the proxy docs up a level, so that they're
directly under "reference docs" instead of nested inside "unleash
concepts".
#### In the `website/remote-content` directory
These are the remote content files. Previously, all of this lived only
in a `readme-fns.js` file, but with the introduction of Edge and proxy
docs, this has been moved into its own directory and refactored into
three files (`shared`, `sdks`, `edge-proxy`).
#### `custom.css`
Style updates to center mermaid diagrams and provide more space around
them.
#### In `static/img`
The image files that were included in the proxy doc and that have been
deleted.
## Why
For two reasons:
1. Reduce duplication for the proxy. Have one source of truth.
2. Add docs for edge.
## Discussion points and review wishes
This is a big PR, and I don't expect anyone to do a line-by-line review
of it, nor do I think that is particularly useful. Instead, I'd like to
ask reviewers to:
1. Visit the [documentation
preview](https://unleash-docs-git-docs-source-proxy-gh-unleash-team.vercel.app/reference/unleash-proxy)
and have a look at both the proxy docs and the Edge docs. Potentially
have a look at the SDK docs too to verify that everything still works.
2. Consider whether they think moving the proxy and edge docs up a level
(in the sidebar) makes sense.
3. Let me know what slug they'd prefer for the Edge docs. I've gone with
`unleash-edge` for now (so that it's
`docs.getunleash.io/reference/unleash-edge`), but we could potentially
also just use `edge`. WDYT?
4. Read through the detailed changes section.
5. Let me know if they have any other concerns or questions.
## Screenies
The new proxy doc:
The new edge doc:
2023-02-16 13:36:28 +01:00
|
|
|
const { sdks } = require('./remote-content/sdks');
|
|
|
|
|
const { docs: edgeAndProxy } = require('./remote-content/edge-proxy');
|
docs: Use Go readme (#2816)
# PR 1: add remote content plugin and rust readme
## What
This PR does a few connected things:
1. It adds the ["docusaurus-plugin-remote-content" package](https://github.com/rdilweb/docusaurus-plugin-remote-content).
2. It adds configuration to make it work with Readmes found on GitHub.
3. It adds the Rust SDK's readme (replacing the link we used to have) as a proof of concept on how to do it.
## Why
With documentation split between GitHub readmes and the official docs, it's hard to keep everything up to date and in sync. It's also quite confusing that some information is only available in some places, but not in others.
We've talked about auto-including readmes from GitHub for a while, so here's a proof of concept (finally) 🥳
The intention is to get this merged and then to migrate the other SDK docs one by one, ensuring that everything in the documentation is also in the readme (so that no info is lost).
## Discussion points
### Generation directory
The current generation method generates the files into `/reference/sdks/<sdk name>`. I think this works for now, but it means it adds auto-generated files into a directory that you can't ignore (at least not yet).
We could instead generate them into `/generated/sdks` and update the slugs so that they still match the expected pattern.
However, this would make the sidebar a little harder to work with (for now). That said, there may be ways around it. It's worth exploring.
### Generation method
By default, this plugin will generate files whenever you build. That (probably) means that you need an internet connection _and_ that you'll end up with a bunch of untracked files.
An option is to only generate the files "manually" and commit them to the repo. That would allow you to build the project without an internet connection and would also remove the need for ignoring the files. We could automate the generation if we wanted to.
## Preview / Screenies
Visit [/reference/sdks/rust](https://unleash-docs-git-docs-include-sdk-readmes-unleash-team.vercel.app/reference/sdks/rust) in the preview to see what it looks like live.
# PR 2: add go readme
This PR changes the docs generation to use the Go SDK's GitHub readme
for the SDK docs instead of a separate document.
## What
The changes in this PR are:
- Delete the existing Go SDK documentation. All the content in this
guide already exists in the Go readme.
- Add the Go SDK to the list of auto-generated readme docs
- Move the readme-related code into a separate module, `readme-fns.js`
(I'm not bullish about the file name: we can change it if you have
suggestions)
- Add a note to the top of all generated readmes saying you'll need an
API url and an API token. The note also links you to the relevant
reference and how-to docs.
## Why
Having two different bits of documentation for the same SDK is
troublesome. By only having the data in one place, we can avoid it going
out of sync and getting stale.
2023-01-05 10:47:49 +01:00
|
|
|
|
docs: add `/docs` redirects to _all_ redirect paths (#2839)
## What
For each defined doc redirect path (that doesn't start with `/docs/`),
this PR adds an additional redirect that starts with `/docs`. The rest
of the path is otherwise identical.
For instance, if we have a redirect that goes from `/user_guide/x`, then
this change will ensure that we also have redirect that goes from
`/docs/user_guide/x`.
## Why
As reported by Roman, we've had some 404s recently when people have
tried to access pages that used to exist (wayyyy back) and that used to
redirect.
The reason these redirects stopped working is that we changed the url
structure recently. Before then, the `createRedirects` function would go
and create redirects that started with `/docs/` for all the paths that
required it. However, now that we've changed the structure of the URLs,
a blanket implementation like that won't work anymore.
Luckily, though, we already have all the redirects for pages we have
moved (just not redirecting from the `/docs/...` paths), so we can map
over the paths and add the missing redirects.
2023-01-05 21:47:04 +01:00
|
|
|
// for a given redirect object, modify it's `from` property such that for every
|
|
|
|
|
// path that doesn't start with `/docs/`, a corresponding path that _does_ start
|
|
|
|
|
// with `/docs/` is added.
|
|
|
|
|
//
|
|
|
|
|
// For instance, given the object
|
|
|
|
|
//
|
|
|
|
|
// {
|
|
|
|
|
// to: '/new/path',
|
|
|
|
|
// from: ['/old/path', '/docs/other/old/path'],
|
|
|
|
|
// }
|
|
|
|
|
//
|
|
|
|
|
// it will produce
|
|
|
|
|
//
|
|
|
|
|
// {
|
|
|
|
|
// to: '/new/path',
|
|
|
|
|
// from: ['/old/path', '/docs/old/path', '/docs/other/old/path'],
|
|
|
|
|
// }
|
|
|
|
|
//
|
|
|
|
|
const addDocsRoutePrefix = ({ from, ...rest }) => {
|
|
|
|
|
const addDocs = (from) => {
|
|
|
|
|
if (Array.isArray(from)) {
|
|
|
|
|
// if `from` is a list, then check each entry
|
|
|
|
|
return from.flatMap(addDocs);
|
|
|
|
|
} else {
|
|
|
|
|
if (from.startsWith('/docs/')) {
|
|
|
|
|
return [from];
|
|
|
|
|
} else {
|
|
|
|
|
return [from, `/docs${from}`];
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
return {
|
|
|
|
|
...rest,
|
|
|
|
|
from: addDocs(from),
|
|
|
|
|
};
|
|
|
|
|
};
|
2021-06-04 11:17:15 +02:00
|
|
|
/** @type {import('@docusaurus/types').DocusaurusConfig} */
|
|
|
|
|
module.exports = {
|
2021-08-17 15:24:37 +02:00
|
|
|
title: 'Unleash',
|
|
|
|
|
tagline: 'The enterprise ready feature toggle service',
|
|
|
|
|
url: 'https://docs.getunleash.io',
|
|
|
|
|
baseUrl: '/',
|
|
|
|
|
onBrokenLinks: 'throw',
|
refactor: move docs into new structure / fix links for SEO (#2416)
## What
This (admittedly massive) PR updates the "physical" documentation
structure and fixes url inconsistencies and SEO problems reported by
marketing. The main points are:
- remove or move directories : advanced, user_guide, deploy, api
- move the files contained within to the appropriate one of topics,
how-to, tutorials, or reference
- update internal doc links and product links to the content
- create client-side redirects for all the urls that have changed.
A number of the files have been renamed in small ways to better match
their url and to make them easier to find. Additionally, the top-level
api directory has been moved to /reference/api/legacy/unleash (see the
discussion points section for more on this).
## Why
When moving our doc structure to diataxis a while back, we left the
"physical' files lying where they were, because it didn't matter much to
the new structure. However, that did introduce some inconsistencies with
where you place docs and how we organize them.
There's also the discrepancies in whether urls us underscores or hyphens
(which isn't necessarily the same as their file name), which has been
annoying me for a while, but now has also been raised by marketing as an
issue in terms of SEO.
## Discussion points
The old, hand-written API docs have been moved from /api to
/reference/api/legacy/unleash. There _is_ a /reference/api/unleash
directory, but this is being populated by the OpenAPI plugin, and mixing
those could only cause trouble. However, I'm unsure about putting
/legacy/ in the title, because the API isn't legacy, the docs are. Maybe
we could use another path? Like /old-docs/ or something? I'd appreciate
some input on this.
2022-11-22 10:05:30 +01:00
|
|
|
onBrokenMarkdownLinks: 'throw',
|
2021-08-17 15:24:37 +02:00
|
|
|
favicon: 'img/favicon.ico',
|
|
|
|
|
organizationName: 'Unleash', // Usually your GitHub org/user name.
|
|
|
|
|
projectName: 'unleash.github.io', // Usually your repo name.
|
|
|
|
|
trailingSlash: false,
|
Source proxy and Edge docs from GitHub (#3122)
## What
The main purpose of this PR is to
1. Delete the proxy docs in this repo and replace them with the proxy's
GitHub readme.
2. Add the docs for Unleash Edge.
### Detailed change description
This PR contains a lot of small changes in a large number of files. To
make it easier to get an overview, here's a detailed description of what
happens where:
#### In the `website/docs`directory
Except for the deletion of the proxy doc, all changes in this directory
are rewriting internal links, so that they point to the newly generated
document instead.
#### `package.json` and `yarn.lock`
When including the documentation for Edge, we also want to render the
mermaid diagrams it uses. Docusaurus supports this via a plugin. All
changes in these files are related to installing that plugin.
#### `docusaurus.config.js`
There's two types of changes in this file:
1. Mermaid-related changes: we ask docusaurus to render mermaid in
markdown files and add the plugin
2. Document generation. There's some rewrites to the sdk doc generation
plus an entirely new section that generates docs for Edge and the proxy
#### `sidebars.js`
Two things:
1. Add the edge docs
2. Move both the Edge and the proxy docs up a level, so that they're
directly under "reference docs" instead of nested inside "unleash
concepts".
#### In the `website/remote-content` directory
These are the remote content files. Previously, all of this lived only
in a `readme-fns.js` file, but with the introduction of Edge and proxy
docs, this has been moved into its own directory and refactored into
three files (`shared`, `sdks`, `edge-proxy`).
#### `custom.css`
Style updates to center mermaid diagrams and provide more space around
them.
#### In `static/img`
The image files that were included in the proxy doc and that have been
deleted.
## Why
For two reasons:
1. Reduce duplication for the proxy. Have one source of truth.
2. Add docs for edge.
## Discussion points and review wishes
This is a big PR, and I don't expect anyone to do a line-by-line review
of it, nor do I think that is particularly useful. Instead, I'd like to
ask reviewers to:
1. Visit the [documentation
preview](https://unleash-docs-git-docs-source-proxy-gh-unleash-team.vercel.app/reference/unleash-proxy)
and have a look at both the proxy docs and the Edge docs. Potentially
have a look at the SDK docs too to verify that everything still works.
2. Consider whether they think moving the proxy and edge docs up a level
(in the sidebar) makes sense.
3. Let me know what slug they'd prefer for the Edge docs. I've gone with
`unleash-edge` for now (so that it's
`docs.getunleash.io/reference/unleash-edge`), but we could potentially
also just use `edge`. WDYT?
4. Read through the detailed changes section.
5. Let me know if they have any other concerns or questions.
## Screenies
The new proxy doc:
The new edge doc:
2023-02-16 13:36:28 +01:00
|
|
|
markdown: { mermaid: true },
|
2022-03-01 17:21:14 +01:00
|
|
|
customFields: {
|
|
|
|
|
// expose env vars etc here
|
|
|
|
|
environment: process.env.NODE_ENV,
|
|
|
|
|
},
|
2021-06-04 11:17:15 +02:00
|
|
|
themeConfig: {
|
|
|
|
|
defaultMode: 'light',
|
|
|
|
|
disableSwitch: true,
|
|
|
|
|
respectPrefersColorScheme: false,
|
2021-06-16 08:52:33 +02:00
|
|
|
algolia: {
|
2022-10-18 13:53:06 +02:00
|
|
|
appId: '5U05JI5NE1',
|
|
|
|
|
apiKey: 'dc9c4491fcf9143ee34015f22d1dd9d6',
|
2021-08-17 15:24:37 +02:00
|
|
|
indexName: 'getunleash',
|
2021-06-16 08:52:33 +02:00
|
|
|
},
|
2021-06-04 11:17:15 +02:00
|
|
|
navbar: {
|
|
|
|
|
logo: {
|
2021-08-17 15:24:37 +02:00
|
|
|
alt: 'Unleash logo',
|
2024-01-29 19:30:18 +01:00
|
|
|
src: 'img/unleash_logo_white.svg',
|
2021-06-04 11:17:15 +02:00
|
|
|
},
|
|
|
|
|
items: [
|
2024-01-29 19:30:18 +01:00
|
|
|
{
|
|
|
|
|
type: 'doc',
|
|
|
|
|
position: 'right',
|
|
|
|
|
docId: 'quickstart',
|
2024-02-06 03:51:40 +01:00
|
|
|
html: '<span class="hide-when-active">Quickstart</span>',
|
2024-01-29 19:30:18 +01:00
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
type: 'doc',
|
|
|
|
|
position: 'right',
|
|
|
|
|
docId: 'welcome',
|
2024-02-06 03:51:40 +01:00
|
|
|
html: '<span class="hide-when-active">Docs</span>',
|
2024-01-29 19:30:18 +01:00
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
type: 'dropdown',
|
|
|
|
|
position: 'right',
|
|
|
|
|
html: '<span class="hide-at-small-sizes">Unleash </span>Academy',
|
|
|
|
|
to: 'unleash-academy/introduction',
|
|
|
|
|
items: [
|
|
|
|
|
{
|
|
|
|
|
type: 'doc',
|
|
|
|
|
docId: 'unleash-academy/foundational',
|
|
|
|
|
label: 'Foundational',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
type: 'doc',
|
|
|
|
|
docId: 'unleash-academy/advanced-for-devs',
|
|
|
|
|
label: 'Advanced for Developers',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
type: 'doc',
|
|
|
|
|
docId: 'unleash-academy/managing-unleash-for-devops',
|
2024-03-13 12:30:40 +01:00
|
|
|
label: 'Managing Unleash for DevOps/Admins',
|
2024-01-29 19:30:18 +01:00
|
|
|
},
|
|
|
|
|
],
|
|
|
|
|
},
|
|
|
|
|
|
|
|
|
|
{
|
|
|
|
|
type: 'dropdown',
|
|
|
|
|
position: 'right',
|
|
|
|
|
html: '<span class="hide-at-small-sizes">Unleash </span>Certification',
|
|
|
|
|
items: [
|
|
|
|
|
{
|
2024-03-13 12:30:40 +01:00
|
|
|
label: 'Foundational Unleash',
|
|
|
|
|
href: 'https://docs.google.com/forms/d/1iPUk2I0k5xMzicn9aLMcPF3b9ub3ZwdVjRxCxWxV7js/viewform',
|
2024-01-29 19:30:18 +01:00
|
|
|
},
|
|
|
|
|
{
|
2024-03-13 12:30:40 +01:00
|
|
|
label: 'Advanced Unleash for Developers',
|
|
|
|
|
href: 'https://docs.google.com/forms/d/1NUL9hyO8Ys916TB6fPV3-jkvD97OmPXZ8_TO84Wjqgc/viewform',
|
2024-01-29 19:30:18 +01:00
|
|
|
},
|
|
|
|
|
{
|
2024-03-13 12:30:40 +01:00
|
|
|
label: 'Managing Unleash for DevOps/Admins',
|
|
|
|
|
href: 'https://docs.google.com/forms/d/1JlIqmXI3P7dj0n-OiUs2IYsYXgmqw23BChaemlSgHJA/viewform',
|
2024-02-06 03:51:40 +01:00
|
|
|
},
|
2024-03-13 12:30:40 +01:00
|
|
|
],
|
2024-01-29 19:30:18 +01:00
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
type: 'html',
|
|
|
|
|
position: 'right',
|
|
|
|
|
value: '<span class="navbar-separator"></span>',
|
|
|
|
|
},
|
2021-08-17 15:24:37 +02:00
|
|
|
{
|
|
|
|
|
href: 'https://www.getunleash.io/plans',
|
2024-01-29 19:30:18 +01:00
|
|
|
label: 'Plans',
|
|
|
|
|
position: 'right',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
href: 'https://app.unleash-hosted.com/sign-in',
|
|
|
|
|
label: 'Sign in',
|
|
|
|
|
position: 'right',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
type: 'html',
|
2021-08-17 15:24:37 +02:00
|
|
|
position: 'right',
|
2024-01-29 19:30:18 +01:00
|
|
|
value: '<span class="navbar-separator"></span>',
|
2021-08-17 15:24:37 +02:00
|
|
|
},
|
2021-06-04 11:17:15 +02:00
|
|
|
{
|
|
|
|
|
href: 'https://github.com/Unleash/unleash',
|
|
|
|
|
position: 'right',
|
|
|
|
|
className: 'header-github-link',
|
2022-01-26 12:22:03 +01:00
|
|
|
'aria-label': 'Unleash GitHub repository',
|
2021-06-04 11:17:15 +02:00
|
|
|
},
|
2021-08-17 15:24:37 +02:00
|
|
|
],
|
2021-06-04 11:17:15 +02:00
|
|
|
},
|
2021-06-04 14:50:52 +02:00
|
|
|
prism: {
|
2023-03-17 11:19:13 +01:00
|
|
|
theme: require('prism-react-renderer/themes/oceanicNext'),
|
2022-01-25 15:19:32 +01:00
|
|
|
additionalLanguages: [
|
|
|
|
|
'csharp',
|
2023-01-25 14:36:50 +01:00
|
|
|
'dart',
|
2022-02-09 15:54:16 +01:00
|
|
|
'http',
|
|
|
|
|
'java',
|
2022-01-25 15:19:32 +01:00
|
|
|
'kotlin',
|
|
|
|
|
'php',
|
2022-02-09 15:54:16 +01:00
|
|
|
'ruby',
|
docs: Use Go readme (#2816)
# PR 1: add remote content plugin and rust readme
## What
This PR does a few connected things:
1. It adds the ["docusaurus-plugin-remote-content" package](https://github.com/rdilweb/docusaurus-plugin-remote-content).
2. It adds configuration to make it work with Readmes found on GitHub.
3. It adds the Rust SDK's readme (replacing the link we used to have) as a proof of concept on how to do it.
## Why
With documentation split between GitHub readmes and the official docs, it's hard to keep everything up to date and in sync. It's also quite confusing that some information is only available in some places, but not in others.
We've talked about auto-including readmes from GitHub for a while, so here's a proof of concept (finally) 🥳
The intention is to get this merged and then to migrate the other SDK docs one by one, ensuring that everything in the documentation is also in the readme (so that no info is lost).
## Discussion points
### Generation directory
The current generation method generates the files into `/reference/sdks/<sdk name>`. I think this works for now, but it means it adds auto-generated files into a directory that you can't ignore (at least not yet).
We could instead generate them into `/generated/sdks` and update the slugs so that they still match the expected pattern.
However, this would make the sidebar a little harder to work with (for now). That said, there may be ways around it. It's worth exploring.
### Generation method
By default, this plugin will generate files whenever you build. That (probably) means that you need an internet connection _and_ that you'll end up with a bunch of untracked files.
An option is to only generate the files "manually" and commit them to the repo. That would allow you to build the project without an internet connection and would also remove the need for ignoring the files. We could automate the generation if we wanted to.
## Preview / Screenies
Visit [/reference/sdks/rust](https://unleash-docs-git-docs-include-sdk-readmes-unleash-team.vercel.app/reference/sdks/rust) in the preview to see what it looks like live.
# PR 2: add go readme
This PR changes the docs generation to use the Go SDK's GitHub readme
for the SDK docs instead of a separate document.
## What
The changes in this PR are:
- Delete the existing Go SDK documentation. All the content in this
guide already exists in the Go readme.
- Add the Go SDK to the list of auto-generated readme docs
- Move the readme-related code into a separate module, `readme-fns.js`
(I'm not bullish about the file name: we can change it if you have
suggestions)
- Add a note to the top of all generated readmes saying you'll need an
API url and an API token. The note also links you to the relevant
reference and how-to docs.
## Why
Having two different bits of documentation for the same SDK is
troublesome. By only having the data in one place, we can avoid it going
out of sync and getting stale.
2023-01-05 10:47:49 +01:00
|
|
|
'rust',
|
2022-02-09 15:54:16 +01:00
|
|
|
'swift',
|
2022-01-25 15:19:32 +01:00
|
|
|
],
|
2021-08-17 15:24:37 +02:00
|
|
|
},
|
2021-06-04 11:17:15 +02:00
|
|
|
footer: {
|
2021-08-17 15:24:37 +02:00
|
|
|
style: 'dark',
|
2021-06-04 11:17:15 +02:00
|
|
|
links: [
|
|
|
|
|
{
|
2021-08-17 15:24:37 +02:00
|
|
|
title: 'Product',
|
2021-06-04 11:17:15 +02:00
|
|
|
items: [
|
|
|
|
|
{
|
2021-08-17 15:24:37 +02:00
|
|
|
label: 'Docs',
|
|
|
|
|
to: '/',
|
2021-08-11 12:55:56 +02:00
|
|
|
},
|
|
|
|
|
{
|
2022-01-26 12:22:03 +01:00
|
|
|
label: 'Unleash on GitHub',
|
2021-08-17 15:24:37 +02:00
|
|
|
href: 'https://github.com/Unleash/unleash',
|
2021-08-11 12:55:56 +02:00
|
|
|
},
|
|
|
|
|
{
|
2021-08-17 15:24:37 +02:00
|
|
|
label: 'Roadmap',
|
2023-01-17 13:26:59 +01:00
|
|
|
href: 'https://github.com/orgs/Unleash/projects/10',
|
2021-08-17 15:24:37 +02:00
|
|
|
},
|
2023-01-18 13:59:43 +01:00
|
|
|
{
|
|
|
|
|
label: 'Unleash help center',
|
|
|
|
|
href: 'https://getunleash.zendesk.com/hc/en-gb',
|
|
|
|
|
},
|
2021-08-17 15:24:37 +02:00
|
|
|
],
|
2021-06-04 11:17:15 +02:00
|
|
|
},
|
|
|
|
|
{
|
2021-08-17 15:24:37 +02:00
|
|
|
title: 'Community',
|
2021-06-04 11:17:15 +02:00
|
|
|
items: [
|
|
|
|
|
{
|
2023-01-17 13:26:59 +01:00
|
|
|
label: 'GitHub discussions',
|
|
|
|
|
href: 'https://github.com/unleash/unleash/discussions/',
|
2021-06-04 11:17:15 +02:00
|
|
|
},
|
|
|
|
|
{
|
2021-08-17 15:24:37 +02:00
|
|
|
label: 'Slack',
|
2022-05-20 08:17:36 +02:00
|
|
|
href: 'https://slack.unleash.run/',
|
2021-06-04 11:17:15 +02:00
|
|
|
},
|
2023-01-17 13:26:59 +01:00
|
|
|
{
|
|
|
|
|
label: 'Stack Overflow',
|
|
|
|
|
href: 'https://stackoverflow.com/questions/tagged/unleash',
|
|
|
|
|
},
|
2021-06-04 11:17:15 +02:00
|
|
|
{
|
2021-08-17 15:24:37 +02:00
|
|
|
label: 'Twitter',
|
|
|
|
|
href: 'https://twitter.com/getunleash',
|
|
|
|
|
},
|
|
|
|
|
],
|
|
|
|
|
},
|
2021-06-04 11:17:15 +02:00
|
|
|
],
|
|
|
|
|
copyright: `Copyright © ${new Date().getFullYear()} Unleash. Built with Docusaurus.`,
|
|
|
|
|
logo: {
|
|
|
|
|
src: 'img/logo.svg',
|
2021-08-17 15:24:37 +02:00
|
|
|
alt: 'Unleash logo',
|
|
|
|
|
},
|
2021-06-04 11:17:15 +02:00
|
|
|
},
|
2021-08-17 15:24:37 +02:00
|
|
|
image: 'img/logo.png',
|
2024-01-09 05:53:56 +01:00
|
|
|
imageZoom: {
|
|
|
|
|
// Optional medium-zoom options at
|
|
|
|
|
// https://www.npmjs.com/package/medium-zoom#options
|
2024-01-11 08:56:57 +01:00
|
|
|
options: {
|
2024-03-13 12:30:40 +01:00
|
|
|
background: 'var(--ifm-background-color)',
|
2024-01-11 08:56:57 +01:00
|
|
|
},
|
2024-03-13 12:30:40 +01:00
|
|
|
},
|
2021-06-04 11:17:15 +02:00
|
|
|
},
|
|
|
|
|
presets: [
|
|
|
|
|
[
|
2021-08-17 15:24:37 +02:00
|
|
|
'@docusaurus/preset-classic',
|
2021-06-04 11:17:15 +02:00
|
|
|
{
|
|
|
|
|
docs: {
|
2021-08-17 15:24:37 +02:00
|
|
|
sidebarPath: require.resolve('./sidebars.js'),
|
2021-06-04 11:17:15 +02:00
|
|
|
// Please change this to your repo.
|
2021-08-17 15:24:37 +02:00
|
|
|
editUrl:
|
2021-12-23 14:12:19 +01:00
|
|
|
'https://github.com/Unleash/unleash/edit/main/website/',
|
2021-08-17 15:24:37 +02:00
|
|
|
routeBasePath: '/',
|
2022-01-03 14:59:47 +01:00
|
|
|
remarkPlugins: [
|
2022-01-25 15:19:32 +01:00
|
|
|
[
|
|
|
|
|
require('@docusaurus/remark-plugin-npm2yarn'),
|
|
|
|
|
{ sync: true },
|
|
|
|
|
],
|
|
|
|
|
],
|
2022-08-12 11:37:57 +02:00
|
|
|
docLayoutComponent: '@theme/DocPage',
|
|
|
|
|
docItemComponent: '@theme/ApiItem',
|
2021-06-04 11:17:15 +02:00
|
|
|
},
|
|
|
|
|
theme: {
|
2021-08-17 15:24:37 +02:00
|
|
|
customCss: require.resolve('./src/css/custom.css'),
|
|
|
|
|
},
|
2022-01-27 13:12:00 +01:00
|
|
|
googleAnalytics: {
|
|
|
|
|
trackingID: 'UA-134882379-1',
|
|
|
|
|
},
|
2023-03-31 07:27:25 +02:00
|
|
|
googleTagManager: {
|
|
|
|
|
containerId: 'GTM-KV5PRR2',
|
|
|
|
|
},
|
2021-08-17 15:24:37 +02:00
|
|
|
},
|
|
|
|
|
],
|
2021-06-04 11:17:15 +02:00
|
|
|
],
|
|
|
|
|
plugins: [
|
|
|
|
|
[
|
2022-09-14 09:59:18 +02:00
|
|
|
// heads up to anyone making redirects:
|
|
|
|
|
//
|
|
|
|
|
// remember that redirects only work in production and not in
|
|
|
|
|
// development, as mentioned in the docs
|
|
|
|
|
// https://docusaurus.io/docs/api/plugins/@docusaurus/plugin-client-redirects/
|
2021-06-04 11:17:15 +02:00
|
|
|
'@docusaurus/plugin-client-redirects',
|
|
|
|
|
{
|
|
|
|
|
fromExtensions: ['html', 'htm'],
|
|
|
|
|
redirects: [
|
|
|
|
|
{
|
refactor: move docs into new structure / fix links for SEO (#2416)
## What
This (admittedly massive) PR updates the "physical" documentation
structure and fixes url inconsistencies and SEO problems reported by
marketing. The main points are:
- remove or move directories : advanced, user_guide, deploy, api
- move the files contained within to the appropriate one of topics,
how-to, tutorials, or reference
- update internal doc links and product links to the content
- create client-side redirects for all the urls that have changed.
A number of the files have been renamed in small ways to better match
their url and to make them easier to find. Additionally, the top-level
api directory has been moved to /reference/api/legacy/unleash (see the
discussion points section for more on this).
## Why
When moving our doc structure to diataxis a while back, we left the
"physical' files lying where they were, because it didn't matter much to
the new structure. However, that did introduce some inconsistencies with
where you place docs and how we organize them.
There's also the discrepancies in whether urls us underscores or hyphens
(which isn't necessarily the same as their file name), which has been
annoying me for a while, but now has also been raised by marketing as an
issue in terms of SEO.
## Discussion points
The old, hand-written API docs have been moved from /api to
/reference/api/legacy/unleash. There _is_ a /reference/api/unleash
directory, but this is being populated by the OpenAPI plugin, and mixing
those could only cause trouble. However, I'm unsure about putting
/legacy/ in the title, because the API isn't legacy, the docs are. Maybe
we could use another path? Like /old-docs/ or something? I'd appreciate
some input on this.
2022-11-22 10:05:30 +01:00
|
|
|
to: '/how-to/how-to-create-api-tokens',
|
2021-08-17 15:24:37 +02:00
|
|
|
from: [
|
refactor: move docs into new structure / fix links for SEO (#2416)
## What
This (admittedly massive) PR updates the "physical" documentation
structure and fixes url inconsistencies and SEO problems reported by
marketing. The main points are:
- remove or move directories : advanced, user_guide, deploy, api
- move the files contained within to the appropriate one of topics,
how-to, tutorials, or reference
- update internal doc links and product links to the content
- create client-side redirects for all the urls that have changed.
A number of the files have been renamed in small ways to better match
their url and to make them easier to find. Additionally, the top-level
api directory has been moved to /reference/api/legacy/unleash (see the
discussion points section for more on this).
## Why
When moving our doc structure to diataxis a while back, we left the
"physical' files lying where they were, because it didn't matter much to
the new structure. However, that did introduce some inconsistencies with
where you place docs and how we organize them.
There's also the discrepancies in whether urls us underscores or hyphens
(which isn't necessarily the same as their file name), which has been
annoying me for a while, but now has also been raised by marketing as an
issue in terms of SEO.
## Discussion points
The old, hand-written API docs have been moved from /api to
/reference/api/legacy/unleash. There _is_ a /reference/api/unleash
directory, but this is being populated by the OpenAPI plugin, and mixing
those could only cause trouble. However, I'm unsure about putting
/legacy/ in the title, because the API isn't legacy, the docs are. Maybe
we could use another path? Like /old-docs/ or something? I'd appreciate
some input on this.
2022-11-22 10:05:30 +01:00
|
|
|
'/user_guide/api-token',
|
|
|
|
|
'/deploy/user_guide/api-token',
|
2021-08-17 15:24:37 +02:00
|
|
|
],
|
2021-06-04 11:17:15 +02:00
|
|
|
},
|
2021-06-10 23:15:14 +02:00
|
|
|
{
|
refactor: move docs into new structure / fix links for SEO (#2416)
## What
This (admittedly massive) PR updates the "physical" documentation
structure and fixes url inconsistencies and SEO problems reported by
marketing. The main points are:
- remove or move directories : advanced, user_guide, deploy, api
- move the files contained within to the appropriate one of topics,
how-to, tutorials, or reference
- update internal doc links and product links to the content
- create client-side redirects for all the urls that have changed.
A number of the files have been renamed in small ways to better match
their url and to make them easier to find. Additionally, the top-level
api directory has been moved to /reference/api/legacy/unleash (see the
discussion points section for more on this).
## Why
When moving our doc structure to diataxis a while back, we left the
"physical' files lying where they were, because it didn't matter much to
the new structure. However, that did introduce some inconsistencies with
where you place docs and how we organize them.
There's also the discrepancies in whether urls us underscores or hyphens
(which isn't necessarily the same as their file name), which has been
annoying me for a while, but now has also been raised by marketing as an
issue in terms of SEO.
## Discussion points
The old, hand-written API docs have been moved from /api to
/reference/api/legacy/unleash. There _is_ a /reference/api/unleash
directory, but this is being populated by the OpenAPI plugin, and mixing
those could only cause trouble. However, I'm unsure about putting
/legacy/ in the title, because the API isn't legacy, the docs are. Maybe
we could use another path? Like /old-docs/ or something? I'd appreciate
some input on this.
2022-11-22 10:05:30 +01:00
|
|
|
from: '/advanced/audit_log',
|
|
|
|
|
to: '/reference/event-log',
|
2021-06-10 23:15:14 +02:00
|
|
|
},
|
|
|
|
|
{
|
refactor: move docs into new structure / fix links for SEO (#2416)
## What
This (admittedly massive) PR updates the "physical" documentation
structure and fixes url inconsistencies and SEO problems reported by
marketing. The main points are:
- remove or move directories : advanced, user_guide, deploy, api
- move the files contained within to the appropriate one of topics,
how-to, tutorials, or reference
- update internal doc links and product links to the content
- create client-side redirects for all the urls that have changed.
A number of the files have been renamed in small ways to better match
their url and to make them easier to find. Additionally, the top-level
api directory has been moved to /reference/api/legacy/unleash (see the
discussion points section for more on this).
## Why
When moving our doc structure to diataxis a while back, we left the
"physical' files lying where they were, because it didn't matter much to
the new structure. However, that did introduce some inconsistencies with
where you place docs and how we organize them.
There's also the discrepancies in whether urls us underscores or hyphens
(which isn't necessarily the same as their file name), which has been
annoying me for a while, but now has also been raised by marketing as an
issue in terms of SEO.
## Discussion points
The old, hand-written API docs have been moved from /api to
/reference/api/legacy/unleash. There _is_ a /reference/api/unleash
directory, but this is being populated by the OpenAPI plugin, and mixing
those could only cause trouble. However, I'm unsure about putting
/legacy/ in the title, because the API isn't legacy, the docs are. Maybe
we could use another path? Like /old-docs/ or something? I'd appreciate
some input on this.
2022-11-22 10:05:30 +01:00
|
|
|
from: '/api/open_api',
|
|
|
|
|
to: '/reference/api/unleash',
|
2021-06-10 23:15:14 +02:00
|
|
|
},
|
2021-06-04 11:17:15 +02:00
|
|
|
{
|
refactor: move docs into new structure / fix links for SEO (#2416)
## What
This (admittedly massive) PR updates the "physical" documentation
structure and fixes url inconsistencies and SEO problems reported by
marketing. The main points are:
- remove or move directories : advanced, user_guide, deploy, api
- move the files contained within to the appropriate one of topics,
how-to, tutorials, or reference
- update internal doc links and product links to the content
- create client-side redirects for all the urls that have changed.
A number of the files have been renamed in small ways to better match
their url and to make them easier to find. Additionally, the top-level
api directory has been moved to /reference/api/legacy/unleash (see the
discussion points section for more on this).
## Why
When moving our doc structure to diataxis a while back, we left the
"physical' files lying where they were, because it didn't matter much to
the new structure. However, that did introduce some inconsistencies with
where you place docs and how we organize them.
There's also the discrepancies in whether urls us underscores or hyphens
(which isn't necessarily the same as their file name), which has been
annoying me for a while, but now has also been raised by marketing as an
issue in terms of SEO.
## Discussion points
The old, hand-written API docs have been moved from /api to
/reference/api/legacy/unleash. There _is_ a /reference/api/unleash
directory, but this is being populated by the OpenAPI plugin, and mixing
those could only cause trouble. However, I'm unsure about putting
/legacy/ in the title, because the API isn't legacy, the docs are. Maybe
we could use another path? Like /old-docs/ or something? I'd appreciate
some input on this.
2022-11-22 10:05:30 +01:00
|
|
|
from: '/advanced/api_access',
|
|
|
|
|
to: '/how-to/how-to-use-the-admin-api',
|
2021-08-17 15:24:37 +02:00
|
|
|
},
|
2022-01-11 10:36:23 +01:00
|
|
|
{
|
refactor: move docs into new structure / fix links for SEO (#2416)
## What
This (admittedly massive) PR updates the "physical" documentation
structure and fixes url inconsistencies and SEO problems reported by
marketing. The main points are:
- remove or move directories : advanced, user_guide, deploy, api
- move the files contained within to the appropriate one of topics,
how-to, tutorials, or reference
- update internal doc links and product links to the content
- create client-side redirects for all the urls that have changed.
A number of the files have been renamed in small ways to better match
their url and to make them easier to find. Additionally, the top-level
api directory has been moved to /reference/api/legacy/unleash (see the
discussion points section for more on this).
## Why
When moving our doc structure to diataxis a while back, we left the
"physical' files lying where they were, because it didn't matter much to
the new structure. However, that did introduce some inconsistencies with
where you place docs and how we organize them.
There's also the discrepancies in whether urls us underscores or hyphens
(which isn't necessarily the same as their file name), which has been
annoying me for a while, but now has also been raised by marketing as an
issue in terms of SEO.
## Discussion points
The old, hand-written API docs have been moved from /api to
/reference/api/legacy/unleash. There _is_ a /reference/api/unleash
directory, but this is being populated by the OpenAPI plugin, and mixing
those could only cause trouble. However, I'm unsure about putting
/legacy/ in the title, because the API isn't legacy, the docs are. Maybe
we could use another path? Like /old-docs/ or something? I'd appreciate
some input on this.
2022-11-22 10:05:30 +01:00
|
|
|
from: '/advanced/archived_toggles',
|
|
|
|
|
to: '/reference/archived-toggles',
|
2022-01-11 10:36:23 +01:00
|
|
|
},
|
2022-01-13 11:05:40 +01:00
|
|
|
{
|
2022-12-12 14:08:13 +01:00
|
|
|
from: [
|
|
|
|
|
'/advanced/custom-activation-strategy',
|
|
|
|
|
'/advanced/custom_activation_strategy',
|
|
|
|
|
],
|
refactor: move docs into new structure / fix links for SEO (#2416)
## What
This (admittedly massive) PR updates the "physical" documentation
structure and fixes url inconsistencies and SEO problems reported by
marketing. The main points are:
- remove or move directories : advanced, user_guide, deploy, api
- move the files contained within to the appropriate one of topics,
how-to, tutorials, or reference
- update internal doc links and product links to the content
- create client-side redirects for all the urls that have changed.
A number of the files have been renamed in small ways to better match
their url and to make them easier to find. Additionally, the top-level
api directory has been moved to /reference/api/legacy/unleash (see the
discussion points section for more on this).
## Why
When moving our doc structure to diataxis a while back, we left the
"physical' files lying where they were, because it didn't matter much to
the new structure. However, that did introduce some inconsistencies with
where you place docs and how we organize them.
There's also the discrepancies in whether urls us underscores or hyphens
(which isn't necessarily the same as their file name), which has been
annoying me for a while, but now has also been raised by marketing as an
issue in terms of SEO.
## Discussion points
The old, hand-written API docs have been moved from /api to
/reference/api/legacy/unleash. There _is_ a /reference/api/unleash
directory, but this is being populated by the OpenAPI plugin, and mixing
those could only cause trouble. However, I'm unsure about putting
/legacy/ in the title, because the API isn't legacy, the docs are. Maybe
we could use another path? Like /old-docs/ or something? I'd appreciate
some input on this.
2022-11-22 10:05:30 +01:00
|
|
|
to: '/reference/custom-activation-strategies',
|
2022-01-13 11:05:40 +01:00
|
|
|
},
|
2022-02-08 12:11:08 +01:00
|
|
|
{
|
refactor: move docs into new structure / fix links for SEO (#2416)
## What
This (admittedly massive) PR updates the "physical" documentation
structure and fixes url inconsistencies and SEO problems reported by
marketing. The main points are:
- remove or move directories : advanced, user_guide, deploy, api
- move the files contained within to the appropriate one of topics,
how-to, tutorials, or reference
- update internal doc links and product links to the content
- create client-side redirects for all the urls that have changed.
A number of the files have been renamed in small ways to better match
their url and to make them easier to find. Additionally, the top-level
api directory has been moved to /reference/api/legacy/unleash (see the
discussion points section for more on this).
## Why
When moving our doc structure to diataxis a while back, we left the
"physical' files lying where they were, because it didn't matter much to
the new structure. However, that did introduce some inconsistencies with
where you place docs and how we organize them.
There's also the discrepancies in whether urls us underscores or hyphens
(which isn't necessarily the same as their file name), which has been
annoying me for a while, but now has also been raised by marketing as an
issue in terms of SEO.
## Discussion points
The old, hand-written API docs have been moved from /api to
/reference/api/legacy/unleash. There _is_ a /reference/api/unleash
directory, but this is being populated by the OpenAPI plugin, and mixing
those could only cause trouble. However, I'm unsure about putting
/legacy/ in the title, because the API isn't legacy, the docs are. Maybe
we could use another path? Like /old-docs/ or something? I'd appreciate
some input on this.
2022-11-22 10:05:30 +01:00
|
|
|
from: '/advanced/feature_toggle_types',
|
|
|
|
|
to: '/reference/feature-toggle-types',
|
2022-03-01 17:21:14 +01:00
|
|
|
},
|
2022-09-14 09:59:18 +02:00
|
|
|
{
|
refactor: move docs into new structure / fix links for SEO (#2416)
## What
This (admittedly massive) PR updates the "physical" documentation
structure and fixes url inconsistencies and SEO problems reported by
marketing. The main points are:
- remove or move directories : advanced, user_guide, deploy, api
- move the files contained within to the appropriate one of topics,
how-to, tutorials, or reference
- update internal doc links and product links to the content
- create client-side redirects for all the urls that have changed.
A number of the files have been renamed in small ways to better match
their url and to make them easier to find. Additionally, the top-level
api directory has been moved to /reference/api/legacy/unleash (see the
discussion points section for more on this).
## Why
When moving our doc structure to diataxis a while back, we left the
"physical' files lying where they were, because it didn't matter much to
the new structure. However, that did introduce some inconsistencies with
where you place docs and how we organize them.
There's also the discrepancies in whether urls us underscores or hyphens
(which isn't necessarily the same as their file name), which has been
annoying me for a while, but now has also been raised by marketing as an
issue in terms of SEO.
## Discussion points
The old, hand-written API docs have been moved from /api to
/reference/api/legacy/unleash. There _is_ a /reference/api/unleash
directory, but this is being populated by the OpenAPI plugin, and mixing
those could only cause trouble. However, I'm unsure about putting
/legacy/ in the title, because the API isn't legacy, the docs are. Maybe
we could use another path? Like /old-docs/ or something? I'd appreciate
some input on this.
2022-11-22 10:05:30 +01:00
|
|
|
from: [
|
|
|
|
|
'/toggle_variants',
|
|
|
|
|
'/advanced/feature_toggle_variants',
|
2022-12-06 09:32:42 +01:00
|
|
|
'/advanced/toggle_variants',
|
refactor: move docs into new structure / fix links for SEO (#2416)
## What
This (admittedly massive) PR updates the "physical" documentation
structure and fixes url inconsistencies and SEO problems reported by
marketing. The main points are:
- remove or move directories : advanced, user_guide, deploy, api
- move the files contained within to the appropriate one of topics,
how-to, tutorials, or reference
- update internal doc links and product links to the content
- create client-side redirects for all the urls that have changed.
A number of the files have been renamed in small ways to better match
their url and to make them easier to find. Additionally, the top-level
api directory has been moved to /reference/api/legacy/unleash (see the
discussion points section for more on this).
## Why
When moving our doc structure to diataxis a while back, we left the
"physical' files lying where they were, because it didn't matter much to
the new structure. However, that did introduce some inconsistencies with
where you place docs and how we organize them.
There's also the discrepancies in whether urls us underscores or hyphens
(which isn't necessarily the same as their file name), which has been
annoying me for a while, but now has also been raised by marketing as an
issue in terms of SEO.
## Discussion points
The old, hand-written API docs have been moved from /api to
/reference/api/legacy/unleash. There _is_ a /reference/api/unleash
directory, but this is being populated by the OpenAPI plugin, and mixing
those could only cause trouble. However, I'm unsure about putting
/legacy/ in the title, because the API isn't legacy, the docs are. Maybe
we could use another path? Like /old-docs/ or something? I'd appreciate
some input on this.
2022-11-22 10:05:30 +01:00
|
|
|
],
|
|
|
|
|
to: '/reference/feature-toggle-variants',
|
2022-09-14 09:59:18 +02:00
|
|
|
},
|
2022-10-19 14:02:00 +02:00
|
|
|
{
|
refactor: move docs into new structure / fix links for SEO (#2416)
## What
This (admittedly massive) PR updates the "physical" documentation
structure and fixes url inconsistencies and SEO problems reported by
marketing. The main points are:
- remove or move directories : advanced, user_guide, deploy, api
- move the files contained within to the appropriate one of topics,
how-to, tutorials, or reference
- update internal doc links and product links to the content
- create client-side redirects for all the urls that have changed.
A number of the files have been renamed in small ways to better match
their url and to make them easier to find. Additionally, the top-level
api directory has been moved to /reference/api/legacy/unleash (see the
discussion points section for more on this).
## Why
When moving our doc structure to diataxis a while back, we left the
"physical' files lying where they were, because it didn't matter much to
the new structure. However, that did introduce some inconsistencies with
where you place docs and how we organize them.
There's also the discrepancies in whether urls us underscores or hyphens
(which isn't necessarily the same as their file name), which has been
annoying me for a while, but now has also been raised by marketing as an
issue in terms of SEO.
## Discussion points
The old, hand-written API docs have been moved from /api to
/reference/api/legacy/unleash. There _is_ a /reference/api/unleash
directory, but this is being populated by the OpenAPI plugin, and mixing
those could only cause trouble. However, I'm unsure about putting
/legacy/ in the title, because the API isn't legacy, the docs are. Maybe
we could use another path? Like /old-docs/ or something? I'd appreciate
some input on this.
2022-11-22 10:05:30 +01:00
|
|
|
from: [
|
|
|
|
|
'/advanced/impression-data',
|
|
|
|
|
'/advanced/impression_data',
|
|
|
|
|
],
|
|
|
|
|
to: '/reference/impression-data',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/advanced/stickiness',
|
|
|
|
|
to: '/reference/stickiness',
|
2022-10-19 14:02:00 +02:00
|
|
|
},
|
2022-11-14 13:11:27 +01:00
|
|
|
{
|
|
|
|
|
from: '/advanced/sso-google',
|
|
|
|
|
to: '/how-to/how-to-add-sso-google',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/advanced/sso-open-id-connect',
|
|
|
|
|
to: '/how-to/how-to-add-sso-open-id-connect',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/advanced/sso-saml-keycloak',
|
|
|
|
|
to: '/how-to/how-to-add-sso-saml-keycloak',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/advanced/sso-saml',
|
|
|
|
|
to: '/how-to/how-to-add-sso-saml',
|
|
|
|
|
},
|
refactor: move docs into new structure / fix links for SEO (#2416)
## What
This (admittedly massive) PR updates the "physical" documentation
structure and fixes url inconsistencies and SEO problems reported by
marketing. The main points are:
- remove or move directories : advanced, user_guide, deploy, api
- move the files contained within to the appropriate one of topics,
how-to, tutorials, or reference
- update internal doc links and product links to the content
- create client-side redirects for all the urls that have changed.
A number of the files have been renamed in small ways to better match
their url and to make them easier to find. Additionally, the top-level
api directory has been moved to /reference/api/legacy/unleash (see the
discussion points section for more on this).
## Why
When moving our doc structure to diataxis a while back, we left the
"physical' files lying where they were, because it didn't matter much to
the new structure. However, that did introduce some inconsistencies with
where you place docs and how we organize them.
There's also the discrepancies in whether urls us underscores or hyphens
(which isn't necessarily the same as their file name), which has been
annoying me for a while, but now has also been raised by marketing as an
issue in terms of SEO.
## Discussion points
The old, hand-written API docs have been moved from /api to
/reference/api/legacy/unleash. There _is_ a /reference/api/unleash
directory, but this is being populated by the OpenAPI plugin, and mixing
those could only cause trouble. However, I'm unsure about putting
/legacy/ in the title, because the API isn't legacy, the docs are. Maybe
we could use another path? Like /old-docs/ or something? I'd appreciate
some input on this.
2022-11-22 10:05:30 +01:00
|
|
|
{
|
|
|
|
|
from: '/advanced/strategy_constraints',
|
|
|
|
|
to: '/reference/strategy-constraints',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/advanced/tags',
|
|
|
|
|
to: '/reference/tags',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/advanced/enterprise-authentication',
|
|
|
|
|
to: '/reference/sso',
|
|
|
|
|
},
|
|
|
|
|
{
|
2023-09-14 15:27:51 +02:00
|
|
|
from: ['/addons', '/reference/addons'],
|
|
|
|
|
to: '/reference/integrations',
|
refactor: move docs into new structure / fix links for SEO (#2416)
## What
This (admittedly massive) PR updates the "physical" documentation
structure and fixes url inconsistencies and SEO problems reported by
marketing. The main points are:
- remove or move directories : advanced, user_guide, deploy, api
- move the files contained within to the appropriate one of topics,
how-to, tutorials, or reference
- update internal doc links and product links to the content
- create client-side redirects for all the urls that have changed.
A number of the files have been renamed in small ways to better match
their url and to make them easier to find. Additionally, the top-level
api directory has been moved to /reference/api/legacy/unleash (see the
discussion points section for more on this).
## Why
When moving our doc structure to diataxis a while back, we left the
"physical' files lying where they were, because it didn't matter much to
the new structure. However, that did introduce some inconsistencies with
where you place docs and how we organize them.
There's also the discrepancies in whether urls us underscores or hyphens
(which isn't necessarily the same as their file name), which has been
annoying me for a while, but now has also been raised by marketing as an
issue in terms of SEO.
## Discussion points
The old, hand-written API docs have been moved from /api to
/reference/api/legacy/unleash. There _is_ a /reference/api/unleash
directory, but this is being populated by the OpenAPI plugin, and mixing
those could only cause trouble. However, I'm unsure about putting
/legacy/ in the title, because the API isn't legacy, the docs are. Maybe
we could use another path? Like /old-docs/ or something? I'd appreciate
some input on this.
2022-11-22 10:05:30 +01:00
|
|
|
},
|
|
|
|
|
{
|
2023-09-14 15:27:51 +02:00
|
|
|
from: ['/addons/datadog', '/reference/addons/datadog'],
|
|
|
|
|
to: '/reference/integrations/datadog',
|
refactor: move docs into new structure / fix links for SEO (#2416)
## What
This (admittedly massive) PR updates the "physical" documentation
structure and fixes url inconsistencies and SEO problems reported by
marketing. The main points are:
- remove or move directories : advanced, user_guide, deploy, api
- move the files contained within to the appropriate one of topics,
how-to, tutorials, or reference
- update internal doc links and product links to the content
- create client-side redirects for all the urls that have changed.
A number of the files have been renamed in small ways to better match
their url and to make them easier to find. Additionally, the top-level
api directory has been moved to /reference/api/legacy/unleash (see the
discussion points section for more on this).
## Why
When moving our doc structure to diataxis a while back, we left the
"physical' files lying where they were, because it didn't matter much to
the new structure. However, that did introduce some inconsistencies with
where you place docs and how we organize them.
There's also the discrepancies in whether urls us underscores or hyphens
(which isn't necessarily the same as their file name), which has been
annoying me for a while, but now has also been raised by marketing as an
issue in terms of SEO.
## Discussion points
The old, hand-written API docs have been moved from /api to
/reference/api/legacy/unleash. There _is_ a /reference/api/unleash
directory, but this is being populated by the OpenAPI plugin, and mixing
those could only cause trouble. However, I'm unsure about putting
/legacy/ in the title, because the API isn't legacy, the docs are. Maybe
we could use another path? Like /old-docs/ or something? I'd appreciate
some input on this.
2022-11-22 10:05:30 +01:00
|
|
|
},
|
|
|
|
|
{
|
2023-09-14 15:27:51 +02:00
|
|
|
from: ['/addons/slack', '/reference/addons/slack'],
|
|
|
|
|
to: '/reference/integrations/slack',
|
refactor: move docs into new structure / fix links for SEO (#2416)
## What
This (admittedly massive) PR updates the "physical" documentation
structure and fixes url inconsistencies and SEO problems reported by
marketing. The main points are:
- remove or move directories : advanced, user_guide, deploy, api
- move the files contained within to the appropriate one of topics,
how-to, tutorials, or reference
- update internal doc links and product links to the content
- create client-side redirects for all the urls that have changed.
A number of the files have been renamed in small ways to better match
their url and to make them easier to find. Additionally, the top-level
api directory has been moved to /reference/api/legacy/unleash (see the
discussion points section for more on this).
## Why
When moving our doc structure to diataxis a while back, we left the
"physical' files lying where they were, because it didn't matter much to
the new structure. However, that did introduce some inconsistencies with
where you place docs and how we organize them.
There's also the discrepancies in whether urls us underscores or hyphens
(which isn't necessarily the same as their file name), which has been
annoying me for a while, but now has also been raised by marketing as an
issue in terms of SEO.
## Discussion points
The old, hand-written API docs have been moved from /api to
/reference/api/legacy/unleash. There _is_ a /reference/api/unleash
directory, but this is being populated by the OpenAPI plugin, and mixing
those could only cause trouble. However, I'm unsure about putting
/legacy/ in the title, because the API isn't legacy, the docs are. Maybe
we could use another path? Like /old-docs/ or something? I'd appreciate
some input on this.
2022-11-22 10:05:30 +01:00
|
|
|
},
|
2023-11-06 15:20:00 +01:00
|
|
|
{
|
2024-03-13 12:30:40 +01:00
|
|
|
from: [
|
|
|
|
|
'/addons/slack-app',
|
|
|
|
|
'/reference/addons/slack-app',
|
|
|
|
|
],
|
2023-11-06 15:20:00 +01:00
|
|
|
to: '/reference/integrations/slack-app',
|
|
|
|
|
},
|
refactor: move docs into new structure / fix links for SEO (#2416)
## What
This (admittedly massive) PR updates the "physical" documentation
structure and fixes url inconsistencies and SEO problems reported by
marketing. The main points are:
- remove or move directories : advanced, user_guide, deploy, api
- move the files contained within to the appropriate one of topics,
how-to, tutorials, or reference
- update internal doc links and product links to the content
- create client-side redirects for all the urls that have changed.
A number of the files have been renamed in small ways to better match
their url and to make them easier to find. Additionally, the top-level
api directory has been moved to /reference/api/legacy/unleash (see the
discussion points section for more on this).
## Why
When moving our doc structure to diataxis a while back, we left the
"physical' files lying where they were, because it didn't matter much to
the new structure. However, that did introduce some inconsistencies with
where you place docs and how we organize them.
There's also the discrepancies in whether urls us underscores or hyphens
(which isn't necessarily the same as their file name), which has been
annoying me for a while, but now has also been raised by marketing as an
issue in terms of SEO.
## Discussion points
The old, hand-written API docs have been moved from /api to
/reference/api/legacy/unleash. There _is_ a /reference/api/unleash
directory, but this is being populated by the OpenAPI plugin, and mixing
those could only cause trouble. However, I'm unsure about putting
/legacy/ in the title, because the API isn't legacy, the docs are. Maybe
we could use another path? Like /old-docs/ or something? I'd appreciate
some input on this.
2022-11-22 10:05:30 +01:00
|
|
|
{
|
2023-09-14 15:27:51 +02:00
|
|
|
from: ['/addons/teams', '/reference/addons/teams'],
|
|
|
|
|
to: '/reference/integrations/teams',
|
refactor: move docs into new structure / fix links for SEO (#2416)
## What
This (admittedly massive) PR updates the "physical" documentation
structure and fixes url inconsistencies and SEO problems reported by
marketing. The main points are:
- remove or move directories : advanced, user_guide, deploy, api
- move the files contained within to the appropriate one of topics,
how-to, tutorials, or reference
- update internal doc links and product links to the content
- create client-side redirects for all the urls that have changed.
A number of the files have been renamed in small ways to better match
their url and to make them easier to find. Additionally, the top-level
api directory has been moved to /reference/api/legacy/unleash (see the
discussion points section for more on this).
## Why
When moving our doc structure to diataxis a while back, we left the
"physical' files lying where they were, because it didn't matter much to
the new structure. However, that did introduce some inconsistencies with
where you place docs and how we organize them.
There's also the discrepancies in whether urls us underscores or hyphens
(which isn't necessarily the same as their file name), which has been
annoying me for a while, but now has also been raised by marketing as an
issue in terms of SEO.
## Discussion points
The old, hand-written API docs have been moved from /api to
/reference/api/legacy/unleash. There _is_ a /reference/api/unleash
directory, but this is being populated by the OpenAPI plugin, and mixing
those could only cause trouble. However, I'm unsure about putting
/legacy/ in the title, because the API isn't legacy, the docs are. Maybe
we could use another path? Like /old-docs/ or something? I'd appreciate
some input on this.
2022-11-22 10:05:30 +01:00
|
|
|
},
|
|
|
|
|
{
|
2023-09-14 15:27:51 +02:00
|
|
|
from: ['/addons/webhook', '/reference/addons/webhook'],
|
|
|
|
|
to: '/reference/integrations/webhook',
|
refactor: move docs into new structure / fix links for SEO (#2416)
## What
This (admittedly massive) PR updates the "physical" documentation
structure and fixes url inconsistencies and SEO problems reported by
marketing. The main points are:
- remove or move directories : advanced, user_guide, deploy, api
- move the files contained within to the appropriate one of topics,
how-to, tutorials, or reference
- update internal doc links and product links to the content
- create client-side redirects for all the urls that have changed.
A number of the files have been renamed in small ways to better match
their url and to make them easier to find. Additionally, the top-level
api directory has been moved to /reference/api/legacy/unleash (see the
discussion points section for more on this).
## Why
When moving our doc structure to diataxis a while back, we left the
"physical' files lying where they were, because it didn't matter much to
the new structure. However, that did introduce some inconsistencies with
where you place docs and how we organize them.
There's also the discrepancies in whether urls us underscores or hyphens
(which isn't necessarily the same as their file name), which has been
annoying me for a while, but now has also been raised by marketing as an
issue in terms of SEO.
## Discussion points
The old, hand-written API docs have been moved from /api to
/reference/api/legacy/unleash. There _is_ a /reference/api/unleash
directory, but this is being populated by the OpenAPI plugin, and mixing
those could only cause trouble. However, I'm unsure about putting
/legacy/ in the title, because the API isn't legacy, the docs are. Maybe
we could use another path? Like /old-docs/ or something? I'd appreciate
some input on this.
2022-11-22 10:05:30 +01:00
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/guides/feature_updates_to_slack',
|
|
|
|
|
to: '/how-to/how-to-send-feature-updates-to-slack-deprecated',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: ['/integrations/integrations', '/integrations'],
|
|
|
|
|
to: '/reference/integrations',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/integrations/jira_server_plugin_installation',
|
|
|
|
|
to: '/reference/integrations/jira-server-plugin-installation',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/integrations/jira_server_plugin_usage',
|
|
|
|
|
to: '/reference/integrations/jira-server-plugin-usage',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: [
|
|
|
|
|
'/sdks',
|
|
|
|
|
'/user_guide/client-sdk',
|
|
|
|
|
'/client-sdk',
|
|
|
|
|
'/user_guide/connect_sdk',
|
|
|
|
|
'/sdks/community',
|
|
|
|
|
],
|
|
|
|
|
to: '/reference/sdks',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/sdks/go_sdk',
|
|
|
|
|
to: '/reference/sdks/go',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/sdks/java_sdk',
|
|
|
|
|
to: '/reference/sdks/java',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/sdks/node_sdk',
|
|
|
|
|
to: '/reference/sdks/node',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/sdks/php_sdk',
|
|
|
|
|
to: '/reference/sdks/php',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/sdks/python_sdk',
|
|
|
|
|
to: '/reference/sdks/python',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/sdks/dot_net_sdk',
|
|
|
|
|
to: '/reference/sdks/dotnet',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/sdks/ruby_sdk',
|
|
|
|
|
to: '/reference/sdks/ruby',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/sdks/android_proxy_sdk',
|
|
|
|
|
to: '/reference/sdks/android-proxy',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/sdks/proxy-ios',
|
|
|
|
|
to: '/reference/sdks/ios-proxy',
|
|
|
|
|
},
|
|
|
|
|
{
|
2022-12-12 14:08:13 +01:00
|
|
|
from: [
|
|
|
|
|
'/sdks/proxy-javascript',
|
|
|
|
|
'/sdks/javascript-browser',
|
|
|
|
|
],
|
refactor: move docs into new structure / fix links for SEO (#2416)
## What
This (admittedly massive) PR updates the "physical" documentation
structure and fixes url inconsistencies and SEO problems reported by
marketing. The main points are:
- remove or move directories : advanced, user_guide, deploy, api
- move the files contained within to the appropriate one of topics,
how-to, tutorials, or reference
- update internal doc links and product links to the content
- create client-side redirects for all the urls that have changed.
A number of the files have been renamed in small ways to better match
their url and to make them easier to find. Additionally, the top-level
api directory has been moved to /reference/api/legacy/unleash (see the
discussion points section for more on this).
## Why
When moving our doc structure to diataxis a while back, we left the
"physical' files lying where they were, because it didn't matter much to
the new structure. However, that did introduce some inconsistencies with
where you place docs and how we organize them.
There's also the discrepancies in whether urls us underscores or hyphens
(which isn't necessarily the same as their file name), which has been
annoying me for a while, but now has also been raised by marketing as an
issue in terms of SEO.
## Discussion points
The old, hand-written API docs have been moved from /api to
/reference/api/legacy/unleash. There _is_ a /reference/api/unleash
directory, but this is being populated by the OpenAPI plugin, and mixing
those could only cause trouble. However, I'm unsure about putting
/legacy/ in the title, because the API isn't legacy, the docs are. Maybe
we could use another path? Like /old-docs/ or something? I'd appreciate
some input on this.
2022-11-22 10:05:30 +01:00
|
|
|
to: '/reference/sdks/javascript-browser',
|
|
|
|
|
},
|
|
|
|
|
{
|
2022-12-12 14:08:13 +01:00
|
|
|
from: ['/sdks/proxy-react', '/sdks/react'],
|
refactor: move docs into new structure / fix links for SEO (#2416)
## What
This (admittedly massive) PR updates the "physical" documentation
structure and fixes url inconsistencies and SEO problems reported by
marketing. The main points are:
- remove or move directories : advanced, user_guide, deploy, api
- move the files contained within to the appropriate one of topics,
how-to, tutorials, or reference
- update internal doc links and product links to the content
- create client-side redirects for all the urls that have changed.
A number of the files have been renamed in small ways to better match
their url and to make them easier to find. Additionally, the top-level
api directory has been moved to /reference/api/legacy/unleash (see the
discussion points section for more on this).
## Why
When moving our doc structure to diataxis a while back, we left the
"physical' files lying where they were, because it didn't matter much to
the new structure. However, that did introduce some inconsistencies with
where you place docs and how we organize them.
There's also the discrepancies in whether urls us underscores or hyphens
(which isn't necessarily the same as their file name), which has been
annoying me for a while, but now has also been raised by marketing as an
issue in terms of SEO.
## Discussion points
The old, hand-written API docs have been moved from /api to
/reference/api/legacy/unleash. There _is_ a /reference/api/unleash
directory, but this is being populated by the OpenAPI plugin, and mixing
those could only cause trouble. However, I'm unsure about putting
/legacy/ in the title, because the API isn't legacy, the docs are. Maybe
we could use another path? Like /old-docs/ or something? I'd appreciate
some input on this.
2022-11-22 10:05:30 +01:00
|
|
|
to: '/reference/sdks/react',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/sdks/proxy-vue',
|
|
|
|
|
to: '/reference/sdks/vue',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/sdks/proxy-svelte',
|
|
|
|
|
to: '/reference/sdks/svelte',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: [
|
|
|
|
|
'/user_guide/native_apps',
|
|
|
|
|
'/user_guide/proxy-api',
|
|
|
|
|
'/sdks/unleash-proxy',
|
|
|
|
|
],
|
|
|
|
|
to: '/reference/unleash-proxy',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
to: '/how-to/how-to-create-feature-toggles',
|
|
|
|
|
from: '/user_guide/create_feature_toggle',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
to: '/reference/activation-strategies',
|
|
|
|
|
from: [
|
|
|
|
|
'/user_guide/control_rollout',
|
|
|
|
|
'/user_guide/activation_strategy',
|
|
|
|
|
],
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/user_guide/environments',
|
|
|
|
|
to: '/reference/environments',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/user_guide/projects',
|
|
|
|
|
to: '/reference/projects',
|
|
|
|
|
},
|
|
|
|
|
{
|
2024-03-13 12:30:40 +01:00
|
|
|
from: ['/user_guide/rbac', '/advanced/groups'],
|
refactor: move docs into new structure / fix links for SEO (#2416)
## What
This (admittedly massive) PR updates the "physical" documentation
structure and fixes url inconsistencies and SEO problems reported by
marketing. The main points are:
- remove or move directories : advanced, user_guide, deploy, api
- move the files contained within to the appropriate one of topics,
how-to, tutorials, or reference
- update internal doc links and product links to the content
- create client-side redirects for all the urls that have changed.
A number of the files have been renamed in small ways to better match
their url and to make them easier to find. Additionally, the top-level
api directory has been moved to /reference/api/legacy/unleash (see the
discussion points section for more on this).
## Why
When moving our doc structure to diataxis a while back, we left the
"physical' files lying where they were, because it didn't matter much to
the new structure. However, that did introduce some inconsistencies with
where you place docs and how we organize them.
There's also the discrepancies in whether urls us underscores or hyphens
(which isn't necessarily the same as their file name), which has been
annoying me for a while, but now has also been raised by marketing as an
issue in terms of SEO.
## Discussion points
The old, hand-written API docs have been moved from /api to
/reference/api/legacy/unleash. There _is_ a /reference/api/unleash
directory, but this is being populated by the OpenAPI plugin, and mixing
those could only cause trouble. However, I'm unsure about putting
/legacy/ in the title, because the API isn't legacy, the docs are. Maybe
we could use another path? Like /old-docs/ or something? I'd appreciate
some input on this.
2022-11-22 10:05:30 +01:00
|
|
|
to: '/reference/rbac',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/user_guide/technical_debt',
|
|
|
|
|
to: '/reference/technical-debt',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/user_guide/unleash_context',
|
|
|
|
|
to: '/reference/unleash-context',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/user_guide/user-management',
|
|
|
|
|
to: '/how-to/how-to-add-users-to-unleash',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/user_guide/v4-whats-new',
|
|
|
|
|
to: '/reference/whats-new-v4',
|
|
|
|
|
},
|
|
|
|
|
{
|
2023-10-31 15:38:03 +01:00
|
|
|
from: [
|
|
|
|
|
'/user_guide/important-concepts',
|
|
|
|
|
'/tutorials/important-concepts',
|
2023-11-17 16:38:33 +01:00
|
|
|
'/reference/concepts/',
|
2023-10-31 15:38:03 +01:00
|
|
|
],
|
|
|
|
|
to: '/reference',
|
refactor: move docs into new structure / fix links for SEO (#2416)
## What
This (admittedly massive) PR updates the "physical" documentation
structure and fixes url inconsistencies and SEO problems reported by
marketing. The main points are:
- remove or move directories : advanced, user_guide, deploy, api
- move the files contained within to the appropriate one of topics,
how-to, tutorials, or reference
- update internal doc links and product links to the content
- create client-side redirects for all the urls that have changed.
A number of the files have been renamed in small ways to better match
their url and to make them easier to find. Additionally, the top-level
api directory has been moved to /reference/api/legacy/unleash (see the
discussion points section for more on this).
## Why
When moving our doc structure to diataxis a while back, we left the
"physical' files lying where they were, because it didn't matter much to
the new structure. However, that did introduce some inconsistencies with
where you place docs and how we organize them.
There's also the discrepancies in whether urls us underscores or hyphens
(which isn't necessarily the same as their file name), which has been
annoying me for a while, but now has also been raised by marketing as an
issue in terms of SEO.
## Discussion points
The old, hand-written API docs have been moved from /api to
/reference/api/legacy/unleash. There _is_ a /reference/api/unleash
directory, but this is being populated by the OpenAPI plugin, and mixing
those could only cause trouble. However, I'm unsure about putting
/legacy/ in the title, because the API isn't legacy, the docs are. Maybe
we could use another path? Like /old-docs/ or something? I'd appreciate
some input on this.
2022-11-22 10:05:30 +01:00
|
|
|
},
|
|
|
|
|
{
|
2022-12-12 14:08:13 +01:00
|
|
|
from: [
|
|
|
|
|
'/user_guide/quickstart',
|
|
|
|
|
'/docs/getting_started',
|
2023-10-10 22:03:17 +02:00
|
|
|
'/tutorials/quickstart',
|
2023-10-31 15:38:03 +01:00
|
|
|
'/tutorials/getting-started',
|
2022-12-12 14:08:13 +01:00
|
|
|
],
|
2023-10-31 15:38:03 +01:00
|
|
|
to: '/quickstart',
|
refactor: move docs into new structure / fix links for SEO (#2416)
## What
This (admittedly massive) PR updates the "physical" documentation
structure and fixes url inconsistencies and SEO problems reported by
marketing. The main points are:
- remove or move directories : advanced, user_guide, deploy, api
- move the files contained within to the appropriate one of topics,
how-to, tutorials, or reference
- update internal doc links and product links to the content
- create client-side redirects for all the urls that have changed.
A number of the files have been renamed in small ways to better match
their url and to make them easier to find. Additionally, the top-level
api directory has been moved to /reference/api/legacy/unleash (see the
discussion points section for more on this).
## Why
When moving our doc structure to diataxis a while back, we left the
"physical' files lying where they were, because it didn't matter much to
the new structure. However, that did introduce some inconsistencies with
where you place docs and how we organize them.
There's also the discrepancies in whether urls us underscores or hyphens
(which isn't necessarily the same as their file name), which has been
annoying me for a while, but now has also been raised by marketing as an
issue in terms of SEO.
## Discussion points
The old, hand-written API docs have been moved from /api to
/reference/api/legacy/unleash. There _is_ a /reference/api/unleash
directory, but this is being populated by the OpenAPI plugin, and mixing
those could only cause trouble. However, I'm unsure about putting
/legacy/ in the title, because the API isn't legacy, the docs are. Maybe
we could use another path? Like /old-docs/ or something? I'd appreciate
some input on this.
2022-11-22 10:05:30 +01:00
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/api/basic-auth',
|
|
|
|
|
to: '/reference/api/legacy/unleash/basic-auth',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/api',
|
|
|
|
|
to: '/reference/api/legacy/unleash',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/api/admin/addons',
|
|
|
|
|
to: '/reference/api/legacy/unleash/admin/addons',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/api/admin/context',
|
|
|
|
|
to: '/reference/api/legacy/unleash/admin/context',
|
|
|
|
|
},
|
|
|
|
|
{
|
docs: add `/docs` redirects to _all_ redirect paths (#2839)
## What
For each defined doc redirect path (that doesn't start with `/docs/`),
this PR adds an additional redirect that starts with `/docs`. The rest
of the path is otherwise identical.
For instance, if we have a redirect that goes from `/user_guide/x`, then
this change will ensure that we also have redirect that goes from
`/docs/user_guide/x`.
## Why
As reported by Roman, we've had some 404s recently when people have
tried to access pages that used to exist (wayyyy back) and that used to
redirect.
The reason these redirects stopped working is that we changed the url
structure recently. Before then, the `createRedirects` function would go
and create redirects that started with `/docs/` for all the paths that
required it. However, now that we've changed the structure of the URLs,
a blanket implementation like that won't work anymore.
Luckily, though, we already have all the redirects for pages we have
moved (just not redirecting from the `/docs/...` paths), so we can map
over the paths and add the missing redirects.
2023-01-05 21:47:04 +01:00
|
|
|
from: '/api/admin/events',
|
refactor: move docs into new structure / fix links for SEO (#2416)
## What
This (admittedly massive) PR updates the "physical" documentation
structure and fixes url inconsistencies and SEO problems reported by
marketing. The main points are:
- remove or move directories : advanced, user_guide, deploy, api
- move the files contained within to the appropriate one of topics,
how-to, tutorials, or reference
- update internal doc links and product links to the content
- create client-side redirects for all the urls that have changed.
A number of the files have been renamed in small ways to better match
their url and to make them easier to find. Additionally, the top-level
api directory has been moved to /reference/api/legacy/unleash (see the
discussion points section for more on this).
## Why
When moving our doc structure to diataxis a while back, we left the
"physical' files lying where they were, because it didn't matter much to
the new structure. However, that did introduce some inconsistencies with
where you place docs and how we organize them.
There's also the discrepancies in whether urls us underscores or hyphens
(which isn't necessarily the same as their file name), which has been
annoying me for a while, but now has also been raised by marketing as an
issue in terms of SEO.
## Discussion points
The old, hand-written API docs have been moved from /api to
/reference/api/legacy/unleash. There _is_ a /reference/api/unleash
directory, but this is being populated by the OpenAPI plugin, and mixing
those could only cause trouble. However, I'm unsure about putting
/legacy/ in the title, because the API isn't legacy, the docs are. Maybe
we could use another path? Like /old-docs/ or something? I'd appreciate
some input on this.
2022-11-22 10:05:30 +01:00
|
|
|
to: '/reference/api/legacy/unleash/admin/events',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/api/admin/feature-toggles-v2',
|
|
|
|
|
to: '/reference/api/legacy/unleash/admin/features-v2',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/api/admin/feature-types',
|
|
|
|
|
to: '/reference/api/legacy/unleash/admin/feature-types',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/api/admin/features',
|
|
|
|
|
to: '/reference/api/legacy/unleash/admin/features',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/api/admin/features-archive',
|
|
|
|
|
to: '/reference/api/legacy/unleash/admin/archive',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/api/admin/metrics',
|
|
|
|
|
to: '/reference/api/legacy/unleash/admin/metrics',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/api/admin/projects',
|
|
|
|
|
to: '/reference/api/legacy/unleash/admin/projects',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/api/admin/segments',
|
|
|
|
|
to: '/reference/api/legacy/unleash/admin/segments',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/api/admin/state',
|
|
|
|
|
to: '/reference/api/legacy/unleash/admin/state',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/api/admin/strategies',
|
|
|
|
|
to: '/reference/api/legacy/unleash/admin/strategies',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/api/admin/tags',
|
|
|
|
|
to: '/reference/api/legacy/unleash/admin/tags',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/api/admin/user-admin',
|
|
|
|
|
to: '/reference/api/legacy/unleash/admin/user-admin',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/api/client/features',
|
|
|
|
|
to: '/reference/api/legacy/unleash/client/features',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/api/client/metrics',
|
|
|
|
|
to: '/reference/api/legacy/unleash/client/metrics',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/api/client/register',
|
|
|
|
|
to: '/reference/api/legacy/unleash/client/register',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/api/internal/internal',
|
|
|
|
|
to: '/reference/api/legacy/unleash/internal/prometheus',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/api/internal/health',
|
|
|
|
|
to: '/reference/api/legacy/unleash/internal/health',
|
|
|
|
|
},
|
docs: add `/docs` redirects to _all_ redirect paths (#2839)
## What
For each defined doc redirect path (that doesn't start with `/docs/`),
this PR adds an additional redirect that starts with `/docs`. The rest
of the path is otherwise identical.
For instance, if we have a redirect that goes from `/user_guide/x`, then
this change will ensure that we also have redirect that goes from
`/docs/user_guide/x`.
## Why
As reported by Roman, we've had some 404s recently when people have
tried to access pages that used to exist (wayyyy back) and that used to
redirect.
The reason these redirects stopped working is that we changed the url
structure recently. Before then, the `createRedirects` function would go
and create redirects that started with `/docs/` for all the paths that
required it. However, now that we've changed the structure of the URLs,
a blanket implementation like that won't work anymore.
Luckily, though, we already have all the redirects for pages we have
moved (just not redirecting from the `/docs/...` paths), so we can map
over the paths and add the missing redirects.
2023-01-05 21:47:04 +01:00
|
|
|
{
|
|
|
|
|
from: '/help',
|
|
|
|
|
to: '/',
|
|
|
|
|
},
|
2023-10-31 15:38:03 +01:00
|
|
|
{
|
2024-03-13 12:30:40 +01:00
|
|
|
from: ['/topics/feature-flags/tutorials', '/tutorials'],
|
2023-10-31 15:38:03 +01:00
|
|
|
to: '/feature-flag-tutorials',
|
2023-12-11 19:07:50 +01:00
|
|
|
},
|
2023-10-31 15:38:03 +01:00
|
|
|
{
|
2024-03-13 12:30:40 +01:00
|
|
|
from: ['/tutorials/academy', '/unleash-academy'],
|
2023-10-31 15:38:03 +01:00
|
|
|
to: '/unleash-academy/introduction',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/tutorials/academy-foundational',
|
|
|
|
|
to: '/unleash-academy/foundational',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/tutorials/academy-advanced-for-devs',
|
|
|
|
|
to: '/unleash-academy/advanced-for-devs',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/tutorials/academy-managing-unleash-for-devops',
|
|
|
|
|
to: '/unleash-academy/managing-unleash-for-devops',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/developer-guide',
|
2024-03-13 12:30:40 +01:00
|
|
|
to: '/contributing',
|
2023-10-31 15:38:03 +01:00
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: [
|
|
|
|
|
'/tutorials/unleash-overview',
|
|
|
|
|
'/user_guide/unleash_overview',
|
|
|
|
|
],
|
|
|
|
|
to: '/understanding-unleash/unleash-overview',
|
|
|
|
|
},
|
|
|
|
|
{
|
2023-11-17 16:38:33 +01:00
|
|
|
from: [
|
|
|
|
|
'/tutorials/managing-constraints',
|
|
|
|
|
'/topics/managing-constraints',
|
|
|
|
|
],
|
2023-10-31 15:38:03 +01:00
|
|
|
to: '/understanding-unleash/managing-constraints',
|
|
|
|
|
},
|
|
|
|
|
{
|
2023-11-17 16:38:33 +01:00
|
|
|
from: [
|
|
|
|
|
'/tutorials/the-anatomy-of-unleash',
|
|
|
|
|
'/topics/the-anatomy-of-unleash',
|
|
|
|
|
],
|
2023-10-31 15:38:03 +01:00
|
|
|
to: '/understanding-unleash/the-anatomy-of-unleash',
|
|
|
|
|
},
|
|
|
|
|
{
|
2023-11-17 16:38:33 +01:00
|
|
|
from: [
|
|
|
|
|
'/tutorials/proxy-hosting',
|
|
|
|
|
'/topics/proxy-hosting',
|
|
|
|
|
],
|
2023-10-31 15:38:03 +01:00
|
|
|
to: '/understanding-unleash/proxy-hosting',
|
|
|
|
|
},
|
|
|
|
|
{
|
2023-11-17 16:38:33 +01:00
|
|
|
from: [
|
|
|
|
|
'/tutorials/data-collection',
|
|
|
|
|
'/topics/data-collection',
|
|
|
|
|
],
|
2023-10-31 15:38:03 +01:00
|
|
|
to: '/understanding-unleash/data-collection',
|
|
|
|
|
},
|
|
|
|
|
|
|
|
|
|
{
|
|
|
|
|
from: '/how-to/how-to-troubleshoot-flag-exposure',
|
|
|
|
|
to: '/using-unleash/troubleshooting/flag-exposure',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/how-to/how-to-troubleshoot-flag-not-returned',
|
|
|
|
|
to: '/using-unleash/troubleshooting/flag-not-returned',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: '/how-to/how-to-troubleshoot-cors',
|
|
|
|
|
to: '/using-unleash/troubleshooting/cors',
|
|
|
|
|
},
|
2024-02-15 15:49:21 +01:00
|
|
|
{
|
|
|
|
|
from: '/how-to/how-to-troubleshoot-https',
|
|
|
|
|
to: '/using-unleash/troubleshooting/https',
|
|
|
|
|
},
|
2023-10-31 15:38:03 +01:00
|
|
|
{
|
|
|
|
|
from: '/how-to/how-to-troubleshoot-feature-not-available',
|
|
|
|
|
to: '/using-unleash/troubleshooting/feature-not-available',
|
|
|
|
|
},
|
2023-11-17 16:38:33 +01:00
|
|
|
{
|
2024-03-13 12:30:40 +01:00
|
|
|
from: ['/reference/deploy', '/deploy'],
|
2023-11-17 16:38:33 +01:00
|
|
|
to: '/using-unleash/deploy',
|
|
|
|
|
},
|
2023-10-31 15:38:03 +01:00
|
|
|
{
|
|
|
|
|
from: [
|
|
|
|
|
'/reference/deploy/getting-started',
|
|
|
|
|
'/deploy/getting_started',
|
|
|
|
|
],
|
|
|
|
|
to: '/using-unleash/deploy/getting-started',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: [
|
|
|
|
|
'/reference/deploy/configuring-unleash',
|
|
|
|
|
'/deploy/configuring_unleash',
|
|
|
|
|
],
|
|
|
|
|
to: '/using-unleash/deploy/configuring-unleash',
|
|
|
|
|
},
|
2023-11-28 10:03:32 +01:00
|
|
|
{
|
|
|
|
|
from: [
|
|
|
|
|
'/reference/deploy/configuring-unleash-v3',
|
|
|
|
|
'/deploy/configuring_unleash_v3',
|
|
|
|
|
],
|
|
|
|
|
to: '/using-unleash/deploy/configuring-unleash-v3',
|
|
|
|
|
},
|
2023-10-31 15:38:03 +01:00
|
|
|
{
|
2023-12-21 17:15:22 +01:00
|
|
|
from: [
|
2023-10-31 15:38:03 +01:00
|
|
|
'/reference/deploy/database-setup',
|
|
|
|
|
'/deploy/database-setup',
|
|
|
|
|
],
|
|
|
|
|
to: '/using-unleash/deploy/database-setup',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: [
|
|
|
|
|
'/reference/deploy/database-backup',
|
|
|
|
|
'/deploy/database-backup',
|
|
|
|
|
],
|
|
|
|
|
to: '/using-unleash/deploy/database-backup',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: [
|
|
|
|
|
'/reference/deploy/email-service',
|
|
|
|
|
'/deploy/email',
|
|
|
|
|
],
|
|
|
|
|
to: '/using-unleash/deploy/email-service',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: [
|
|
|
|
|
'/reference/deploy/google-auth-hook',
|
|
|
|
|
'/deploy/google_auth',
|
|
|
|
|
],
|
|
|
|
|
to: '/using-unleash/deploy/google-auth-hook',
|
|
|
|
|
},
|
|
|
|
|
{
|
2023-12-21 17:15:22 +01:00
|
|
|
from: [
|
2023-10-31 15:38:03 +01:00
|
|
|
'/deploy/migration_guide',
|
|
|
|
|
'/reference/deploy/migration-guide',
|
2023-11-06 15:20:00 +01:00
|
|
|
],
|
2023-10-31 15:38:03 +01:00
|
|
|
to: '/using-unleash/deploy/upgrading-unleash',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: [
|
|
|
|
|
'/reference/deploy/securing-unleash',
|
|
|
|
|
'/deploy/securing_unleash',
|
|
|
|
|
],
|
|
|
|
|
to: '/using-unleash/deploy/securing-unleash',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: [
|
|
|
|
|
'/reference/deploy/import-export',
|
|
|
|
|
'/deploy/import_export',
|
|
|
|
|
],
|
|
|
|
|
to: '/how-to/how-to-import-export',
|
|
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
from: [
|
|
|
|
|
'/reference/deploy/environment-import-export',
|
|
|
|
|
'/deploy/environment-import-export',
|
|
|
|
|
],
|
|
|
|
|
to: '/how-to/how-to-environment-import-export',
|
|
|
|
|
},
|
docs: add `/docs` redirects to _all_ redirect paths (#2839)
## What
For each defined doc redirect path (that doesn't start with `/docs/`),
this PR adds an additional redirect that starts with `/docs`. The rest
of the path is otherwise identical.
For instance, if we have a redirect that goes from `/user_guide/x`, then
this change will ensure that we also have redirect that goes from
`/docs/user_guide/x`.
## Why
As reported by Roman, we've had some 404s recently when people have
tried to access pages that used to exist (wayyyy back) and that used to
redirect.
The reason these redirects stopped working is that we changed the url
structure recently. Before then, the `createRedirects` function would go
and create redirects that started with `/docs/` for all the paths that
required it. However, now that we've changed the structure of the URLs,
a blanket implementation like that won't work anymore.
Luckily, though, we already have all the redirects for pages we have
moved (just not redirecting from the `/docs/...` paths), so we can map
over the paths and add the missing redirects.
2023-01-05 21:47:04 +01:00
|
|
|
].map(addDocsRoutePrefix), // add /docs prefixes
|
2024-03-13 12:30:40 +01:00
|
|
|
createRedirects: (toPath) => {
|
2021-08-17 15:24:37 +02:00
|
|
|
if (
|
|
|
|
|
toPath.indexOf('/docs/') === -1 &&
|
|
|
|
|
toPath.indexOf('index.html') === -1
|
|
|
|
|
) {
|
|
|
|
|
return `/docs/${toPath}`;
|
2021-06-04 11:17:15 +02:00
|
|
|
}
|
2021-08-17 15:24:37 +02:00
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
],
|
Add OpenAPI docs (#1391) (#2066)
## What
This PR (finally 🎉) adds generated OpenAPI docs to the official Unleash documentation. In addition to generating docs when things get merged to main, it also pushes new doc updates every day at 12:00 AM (cron `@daily`).
## Why
Now that we have OpenAPI'd all the things, we can finally start using it. This will allow us to remove hand-written api docs from the documentation and should make sure everything is always kept up to date.
### Generating from us-hosted (Unleash enterprise)
Unleash has several different versions (open source, pro, enterprise). The versions do not necessarily have the exact same api surface. In fact, the enterprise version has a few endpoints that open source does not.
Because we want to have _all_ endpoints listed in the documentation we need to generated the docs from an enterprise spec. Which brings us into the next point:
### The need for scheduled jobs
Regarding the daily scheduled tasks to update the documentation: why do we need that?
The docs are generated from the tip of the main branch. For most of the docs, this is good and something that we want. However, because the OpenAPI docs are generated from the enterprise edition, it _will not be in sync_ with the open source main branch.
Also, we probably do not want the docs to list the current bleeding edge api changes. Instead, we should prefer to use the latest enterprise release (roughly). However, because we don't get notified when this version is released and deployed, we'll instead run the API generation on a daily cadence.
This isn't the perfect solution, but it's simple and gets us 80% of the way there. More intricate solutions can be set up later.
## How
- By adding a scheduled workflow to the generate docs config.
- By adding .gitignore entries for the generated files
There's also some minor changes in styling etc.
## Dependencies
This is dependent on the changes introduced in #2062 having propagated to the enterprise release, which will probably not be for another week or so.
## Discussion
What should the API reference docs url be? I've set it to be `/reference/api/unleash/*` for now, but I'm on the fence about whether it should be `apis` or `api` in there. I also want to get the proxy and other APIs in there as we grow.
-------
## Commits
* docs: style openapi operation buttons
* docs: minor operation badge adjustments
* docs: use permalink to css snippet i copied
* docs: ignore files related to openapi generation
* docs: re-enable openapi docs
* Docs(#1391): prep for integration
* docs(#1391): run docs generation daily
* docs(#1391): add generation step to doc prs too
* docs(#1391): use the US hosted instance to generate docs
* docs(#1391): move doc generation into build command
* docs(#1391): use `/reference/api/*` instead of `/reference/apis/*`
2022-09-19 14:50:24 +02:00
|
|
|
[
|
|
|
|
|
'docusaurus-plugin-openapi-docs',
|
|
|
|
|
{
|
|
|
|
|
id: 'api-operations',
|
|
|
|
|
docsPluginId: 'classic',
|
|
|
|
|
config: {
|
|
|
|
|
server: {
|
|
|
|
|
specPath:
|
#1391: add generated doc cleaning script (#2077)
* #1391: add generated doc cleaning script
## What
The cleaning script replaces all references to the Unleash ushosted instance in the
generated OpenAPI docs. It removes extra path segments (such as leading
`/ushosted` instances) and replaces the ushosted base url with something
user-agnostic.
## Why
When we host the OpenAPI docs in our official documentation, the generated
docs shouldn't necessarily point at _one specific instance_, and especially
not one that the reader is unlikely to ever use. Instead, we can remove all
the bits that are specific to the generation source we use, and make the docs
easier to use. In particular, removing the leading `/ushosted` is likely to
save us loooots of questions.
* #1391: change env var used for generating openapi from localhost
Using NODE_ENV=development doesn't necessarily make sense, so adding
an extra variable sounds reasonable to me.
* #1391: ensure that all generation commands also clean docs
* #1391: change <your-unleash-instance-url> to <your-unleash-url>
* #1391: fix ushosted replacement: not all paths start with /api
* #1391: chore: remove potential `ushosted` ending of api url
In the event that we change the base URL of OpenAPI, so that paths
don't start with `/ushosted/`, the script should still work, changing
those paths into <your-unleash-url> too.
Additionally, remove all instances of `/ushosted` that we find. In the
event that some things switch around or whatever.
2022-09-20 12:43:39 +02:00
|
|
|
process.env.OPENAPI_SOURCE === 'localhost'
|
Add OpenAPI docs (#1391) (#2066)
## What
This PR (finally 🎉) adds generated OpenAPI docs to the official Unleash documentation. In addition to generating docs when things get merged to main, it also pushes new doc updates every day at 12:00 AM (cron `@daily`).
## Why
Now that we have OpenAPI'd all the things, we can finally start using it. This will allow us to remove hand-written api docs from the documentation and should make sure everything is always kept up to date.
### Generating from us-hosted (Unleash enterprise)
Unleash has several different versions (open source, pro, enterprise). The versions do not necessarily have the exact same api surface. In fact, the enterprise version has a few endpoints that open source does not.
Because we want to have _all_ endpoints listed in the documentation we need to generated the docs from an enterprise spec. Which brings us into the next point:
### The need for scheduled jobs
Regarding the daily scheduled tasks to update the documentation: why do we need that?
The docs are generated from the tip of the main branch. For most of the docs, this is good and something that we want. However, because the OpenAPI docs are generated from the enterprise edition, it _will not be in sync_ with the open source main branch.
Also, we probably do not want the docs to list the current bleeding edge api changes. Instead, we should prefer to use the latest enterprise release (roughly). However, because we don't get notified when this version is released and deployed, we'll instead run the API generation on a daily cadence.
This isn't the perfect solution, but it's simple and gets us 80% of the way there. More intricate solutions can be set up later.
## How
- By adding a scheduled workflow to the generate docs config.
- By adding .gitignore entries for the generated files
There's also some minor changes in styling etc.
## Dependencies
This is dependent on the changes introduced in #2062 having propagated to the enterprise release, which will probably not be for another week or so.
## Discussion
What should the API reference docs url be? I've set it to be `/reference/api/unleash/*` for now, but I'm on the fence about whether it should be `apis` or `api` in there. I also want to get the proxy and other APIs in there as we grow.
-------
## Commits
* docs: style openapi operation buttons
* docs: minor operation badge adjustments
* docs: use permalink to css snippet i copied
* docs: ignore files related to openapi generation
* docs: re-enable openapi docs
* Docs(#1391): prep for integration
* docs(#1391): run docs generation daily
* docs(#1391): add generation step to doc prs too
* docs(#1391): use the US hosted instance to generate docs
* docs(#1391): move doc generation into build command
* docs(#1391): use `/reference/api/*` instead of `/reference/apis/*`
2022-09-19 14:50:24 +02:00
|
|
|
? 'http://localhost:4242/docs/openapi.json'
|
|
|
|
|
: 'https://us.app.unleash-hosted.com/ushosted/docs/openapi.json',
|
|
|
|
|
outputDir: 'docs/reference/api/unleash',
|
|
|
|
|
sidebarOptions: {
|
|
|
|
|
groupPathsBy: 'tag',
|
|
|
|
|
categoryLinkSource: 'tag',
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
],
|
docs: Use Go readme (#2816)
# PR 1: add remote content plugin and rust readme
## What
This PR does a few connected things:
1. It adds the ["docusaurus-plugin-remote-content" package](https://github.com/rdilweb/docusaurus-plugin-remote-content).
2. It adds configuration to make it work with Readmes found on GitHub.
3. It adds the Rust SDK's readme (replacing the link we used to have) as a proof of concept on how to do it.
## Why
With documentation split between GitHub readmes and the official docs, it's hard to keep everything up to date and in sync. It's also quite confusing that some information is only available in some places, but not in others.
We've talked about auto-including readmes from GitHub for a while, so here's a proof of concept (finally) 🥳
The intention is to get this merged and then to migrate the other SDK docs one by one, ensuring that everything in the documentation is also in the readme (so that no info is lost).
## Discussion points
### Generation directory
The current generation method generates the files into `/reference/sdks/<sdk name>`. I think this works for now, but it means it adds auto-generated files into a directory that you can't ignore (at least not yet).
We could instead generate them into `/generated/sdks` and update the slugs so that they still match the expected pattern.
However, this would make the sidebar a little harder to work with (for now). That said, there may be ways around it. It's worth exploring.
### Generation method
By default, this plugin will generate files whenever you build. That (probably) means that you need an internet connection _and_ that you'll end up with a bunch of untracked files.
An option is to only generate the files "manually" and commit them to the repo. That would allow you to build the project without an internet connection and would also remove the need for ignoring the files. We could automate the generation if we wanted to.
## Preview / Screenies
Visit [/reference/sdks/rust](https://unleash-docs-git-docs-include-sdk-readmes-unleash-team.vercel.app/reference/sdks/rust) in the preview to see what it looks like live.
# PR 2: add go readme
This PR changes the docs generation to use the Go SDK's GitHub readme
for the SDK docs instead of a separate document.
## What
The changes in this PR are:
- Delete the existing Go SDK documentation. All the content in this
guide already exists in the Go readme.
- Add the Go SDK to the list of auto-generated readme docs
- Move the readme-related code into a separate module, `readme-fns.js`
(I'm not bullish about the file name: we can change it if you have
suggestions)
- Add a note to the top of all generated readmes saying you'll need an
API url and an API token. The note also links you to the relevant
reference and how-to docs.
## Why
Having two different bits of documentation for the same SDK is
troublesome. By only having the data in one place, we can avoid it going
out of sync and getting stale.
2023-01-05 10:47:49 +01:00
|
|
|
[
|
|
|
|
|
'docusaurus-plugin-remote-content',
|
|
|
|
|
{
|
|
|
|
|
// more info at https://github.com/rdilweb/docusaurus-plugin-remote-content#options
|
|
|
|
|
name: 'content-sdks',
|
|
|
|
|
sourceBaseUrl: 'https://raw.githubusercontent.com/Unleash/', // gets prepended to all of the documents when fetching
|
Source proxy and Edge docs from GitHub (#3122)
## What
The main purpose of this PR is to
1. Delete the proxy docs in this repo and replace them with the proxy's
GitHub readme.
2. Add the docs for Unleash Edge.
### Detailed change description
This PR contains a lot of small changes in a large number of files. To
make it easier to get an overview, here's a detailed description of what
happens where:
#### In the `website/docs`directory
Except for the deletion of the proxy doc, all changes in this directory
are rewriting internal links, so that they point to the newly generated
document instead.
#### `package.json` and `yarn.lock`
When including the documentation for Edge, we also want to render the
mermaid diagrams it uses. Docusaurus supports this via a plugin. All
changes in these files are related to installing that plugin.
#### `docusaurus.config.js`
There's two types of changes in this file:
1. Mermaid-related changes: we ask docusaurus to render mermaid in
markdown files and add the plugin
2. Document generation. There's some rewrites to the sdk doc generation
plus an entirely new section that generates docs for Edge and the proxy
#### `sidebars.js`
Two things:
1. Add the edge docs
2. Move both the Edge and the proxy docs up a level, so that they're
directly under "reference docs" instead of nested inside "unleash
concepts".
#### In the `website/remote-content` directory
These are the remote content files. Previously, all of this lived only
in a `readme-fns.js` file, but with the introduction of Edge and proxy
docs, this has been moved into its own directory and refactored into
three files (`shared`, `sdks`, `edge-proxy`).
#### `custom.css`
Style updates to center mermaid diagrams and provide more space around
them.
#### In `static/img`
The image files that were included in the proxy doc and that have been
deleted.
## Why
For two reasons:
1. Reduce duplication for the proxy. Have one source of truth.
2. Add docs for edge.
## Discussion points and review wishes
This is a big PR, and I don't expect anyone to do a line-by-line review
of it, nor do I think that is particularly useful. Instead, I'd like to
ask reviewers to:
1. Visit the [documentation
preview](https://unleash-docs-git-docs-source-proxy-gh-unleash-team.vercel.app/reference/unleash-proxy)
and have a look at both the proxy docs and the Edge docs. Potentially
have a look at the SDK docs too to verify that everything still works.
2. Consider whether they think moving the proxy and edge docs up a level
(in the sidebar) makes sense.
3. Let me know what slug they'd prefer for the Edge docs. I've gone with
`unleash-edge` for now (so that it's
`docs.getunleash.io/reference/unleash-edge`), but we could potentially
also just use `edge`. WDYT?
4. Read through the detailed changes section.
5. Let me know if they have any other concerns or questions.
## Screenies
The new proxy doc:
The new edge doc:
2023-02-16 13:36:28 +01:00
|
|
|
outDir: 'docs/generated', // the base directory to output to.
|
|
|
|
|
documents: sdks.urls, // the file names to download
|
|
|
|
|
modifyContent: sdks.modifyContent,
|
2023-11-06 13:13:58 +01:00
|
|
|
noRuntimeDownloads: true,
|
docs: Use Go readme (#2816)
# PR 1: add remote content plugin and rust readme
## What
This PR does a few connected things:
1. It adds the ["docusaurus-plugin-remote-content" package](https://github.com/rdilweb/docusaurus-plugin-remote-content).
2. It adds configuration to make it work with Readmes found on GitHub.
3. It adds the Rust SDK's readme (replacing the link we used to have) as a proof of concept on how to do it.
## Why
With documentation split between GitHub readmes and the official docs, it's hard to keep everything up to date and in sync. It's also quite confusing that some information is only available in some places, but not in others.
We've talked about auto-including readmes from GitHub for a while, so here's a proof of concept (finally) 🥳
The intention is to get this merged and then to migrate the other SDK docs one by one, ensuring that everything in the documentation is also in the readme (so that no info is lost).
## Discussion points
### Generation directory
The current generation method generates the files into `/reference/sdks/<sdk name>`. I think this works for now, but it means it adds auto-generated files into a directory that you can't ignore (at least not yet).
We could instead generate them into `/generated/sdks` and update the slugs so that they still match the expected pattern.
However, this would make the sidebar a little harder to work with (for now). That said, there may be ways around it. It's worth exploring.
### Generation method
By default, this plugin will generate files whenever you build. That (probably) means that you need an internet connection _and_ that you'll end up with a bunch of untracked files.
An option is to only generate the files "manually" and commit them to the repo. That would allow you to build the project without an internet connection and would also remove the need for ignoring the files. We could automate the generation if we wanted to.
## Preview / Screenies
Visit [/reference/sdks/rust](https://unleash-docs-git-docs-include-sdk-readmes-unleash-team.vercel.app/reference/sdks/rust) in the preview to see what it looks like live.
# PR 2: add go readme
This PR changes the docs generation to use the Go SDK's GitHub readme
for the SDK docs instead of a separate document.
## What
The changes in this PR are:
- Delete the existing Go SDK documentation. All the content in this
guide already exists in the Go readme.
- Add the Go SDK to the list of auto-generated readme docs
- Move the readme-related code into a separate module, `readme-fns.js`
(I'm not bullish about the file name: we can change it if you have
suggestions)
- Add a note to the top of all generated readmes saying you'll need an
API url and an API token. The note also links you to the relevant
reference and how-to docs.
## Why
Having two different bits of documentation for the same SDK is
troublesome. By only having the data in one place, we can avoid it going
out of sync and getting stale.
2023-01-05 10:47:49 +01:00
|
|
|
},
|
|
|
|
|
],
|
Source proxy and Edge docs from GitHub (#3122)
## What
The main purpose of this PR is to
1. Delete the proxy docs in this repo and replace them with the proxy's
GitHub readme.
2. Add the docs for Unleash Edge.
### Detailed change description
This PR contains a lot of small changes in a large number of files. To
make it easier to get an overview, here's a detailed description of what
happens where:
#### In the `website/docs`directory
Except for the deletion of the proxy doc, all changes in this directory
are rewriting internal links, so that they point to the newly generated
document instead.
#### `package.json` and `yarn.lock`
When including the documentation for Edge, we also want to render the
mermaid diagrams it uses. Docusaurus supports this via a plugin. All
changes in these files are related to installing that plugin.
#### `docusaurus.config.js`
There's two types of changes in this file:
1. Mermaid-related changes: we ask docusaurus to render mermaid in
markdown files and add the plugin
2. Document generation. There's some rewrites to the sdk doc generation
plus an entirely new section that generates docs for Edge and the proxy
#### `sidebars.js`
Two things:
1. Add the edge docs
2. Move both the Edge and the proxy docs up a level, so that they're
directly under "reference docs" instead of nested inside "unleash
concepts".
#### In the `website/remote-content` directory
These are the remote content files. Previously, all of this lived only
in a `readme-fns.js` file, but with the introduction of Edge and proxy
docs, this has been moved into its own directory and refactored into
three files (`shared`, `sdks`, `edge-proxy`).
#### `custom.css`
Style updates to center mermaid diagrams and provide more space around
them.
#### In `static/img`
The image files that were included in the proxy doc and that have been
deleted.
## Why
For two reasons:
1. Reduce duplication for the proxy. Have one source of truth.
2. Add docs for edge.
## Discussion points and review wishes
This is a big PR, and I don't expect anyone to do a line-by-line review
of it, nor do I think that is particularly useful. Instead, I'd like to
ask reviewers to:
1. Visit the [documentation
preview](https://unleash-docs-git-docs-source-proxy-gh-unleash-team.vercel.app/reference/unleash-proxy)
and have a look at both the proxy docs and the Edge docs. Potentially
have a look at the SDK docs too to verify that everything still works.
2. Consider whether they think moving the proxy and edge docs up a level
(in the sidebar) makes sense.
3. Let me know what slug they'd prefer for the Edge docs. I've gone with
`unleash-edge` for now (so that it's
`docs.getunleash.io/reference/unleash-edge`), but we could potentially
also just use `edge`. WDYT?
4. Read through the detailed changes section.
5. Let me know if they have any other concerns or questions.
## Screenies
The new proxy doc:
The new edge doc:
2023-02-16 13:36:28 +01:00
|
|
|
[
|
|
|
|
|
'docusaurus-plugin-remote-content',
|
|
|
|
|
{
|
|
|
|
|
// more info at https://github.com/rdilweb/docusaurus-plugin-remote-content#options
|
|
|
|
|
name: 'content-external',
|
|
|
|
|
sourceBaseUrl: 'https://raw.githubusercontent.com/Unleash/', // gets prepended to all of the documents when fetching
|
|
|
|
|
outDir: 'docs/generated/', // the base directory to output to.
|
|
|
|
|
documents: edgeAndProxy.urls, // the file names to download
|
|
|
|
|
modifyContent: edgeAndProxy.modifyContent,
|
2023-11-06 13:13:58 +01:00
|
|
|
noRuntimeDownloads: true,
|
Source proxy and Edge docs from GitHub (#3122)
## What
The main purpose of this PR is to
1. Delete the proxy docs in this repo and replace them with the proxy's
GitHub readme.
2. Add the docs for Unleash Edge.
### Detailed change description
This PR contains a lot of small changes in a large number of files. To
make it easier to get an overview, here's a detailed description of what
happens where:
#### In the `website/docs`directory
Except for the deletion of the proxy doc, all changes in this directory
are rewriting internal links, so that they point to the newly generated
document instead.
#### `package.json` and `yarn.lock`
When including the documentation for Edge, we also want to render the
mermaid diagrams it uses. Docusaurus supports this via a plugin. All
changes in these files are related to installing that plugin.
#### `docusaurus.config.js`
There's two types of changes in this file:
1. Mermaid-related changes: we ask docusaurus to render mermaid in
markdown files and add the plugin
2. Document generation. There's some rewrites to the sdk doc generation
plus an entirely new section that generates docs for Edge and the proxy
#### `sidebars.js`
Two things:
1. Add the edge docs
2. Move both the Edge and the proxy docs up a level, so that they're
directly under "reference docs" instead of nested inside "unleash
concepts".
#### In the `website/remote-content` directory
These are the remote content files. Previously, all of this lived only
in a `readme-fns.js` file, but with the introduction of Edge and proxy
docs, this has been moved into its own directory and refactored into
three files (`shared`, `sdks`, `edge-proxy`).
#### `custom.css`
Style updates to center mermaid diagrams and provide more space around
them.
#### In `static/img`
The image files that were included in the proxy doc and that have been
deleted.
## Why
For two reasons:
1. Reduce duplication for the proxy. Have one source of truth.
2. Add docs for edge.
## Discussion points and review wishes
This is a big PR, and I don't expect anyone to do a line-by-line review
of it, nor do I think that is particularly useful. Instead, I'd like to
ask reviewers to:
1. Visit the [documentation
preview](https://unleash-docs-git-docs-source-proxy-gh-unleash-team.vercel.app/reference/unleash-proxy)
and have a look at both the proxy docs and the Edge docs. Potentially
have a look at the SDK docs too to verify that everything still works.
2. Consider whether they think moving the proxy and edge docs up a level
(in the sidebar) makes sense.
3. Let me know what slug they'd prefer for the Edge docs. I've gone with
`unleash-edge` for now (so that it's
`docs.getunleash.io/reference/unleash-edge`), but we could potentially
also just use `edge`. WDYT?
4. Read through the detailed changes section.
5. Let me know if they have any other concerns or questions.
## Screenies
The new proxy doc:
The new edge doc:
2023-02-16 13:36:28 +01:00
|
|
|
},
|
|
|
|
|
],
|
2024-01-09 05:53:56 +01:00
|
|
|
'plugin-image-zoom',
|
Source proxy and Edge docs from GitHub (#3122)
## What
The main purpose of this PR is to
1. Delete the proxy docs in this repo and replace them with the proxy's
GitHub readme.
2. Add the docs for Unleash Edge.
### Detailed change description
This PR contains a lot of small changes in a large number of files. To
make it easier to get an overview, here's a detailed description of what
happens where:
#### In the `website/docs`directory
Except for the deletion of the proxy doc, all changes in this directory
are rewriting internal links, so that they point to the newly generated
document instead.
#### `package.json` and `yarn.lock`
When including the documentation for Edge, we also want to render the
mermaid diagrams it uses. Docusaurus supports this via a plugin. All
changes in these files are related to installing that plugin.
#### `docusaurus.config.js`
There's two types of changes in this file:
1. Mermaid-related changes: we ask docusaurus to render mermaid in
markdown files and add the plugin
2. Document generation. There's some rewrites to the sdk doc generation
plus an entirely new section that generates docs for Edge and the proxy
#### `sidebars.js`
Two things:
1. Add the edge docs
2. Move both the Edge and the proxy docs up a level, so that they're
directly under "reference docs" instead of nested inside "unleash
concepts".
#### In the `website/remote-content` directory
These are the remote content files. Previously, all of this lived only
in a `readme-fns.js` file, but with the introduction of Edge and proxy
docs, this has been moved into its own directory and refactored into
three files (`shared`, `sdks`, `edge-proxy`).
#### `custom.css`
Style updates to center mermaid diagrams and provide more space around
them.
#### In `static/img`
The image files that were included in the proxy doc and that have been
deleted.
## Why
For two reasons:
1. Reduce duplication for the proxy. Have one source of truth.
2. Add docs for edge.
## Discussion points and review wishes
This is a big PR, and I don't expect anyone to do a line-by-line review
of it, nor do I think that is particularly useful. Instead, I'd like to
ask reviewers to:
1. Visit the [documentation
preview](https://unleash-docs-git-docs-source-proxy-gh-unleash-team.vercel.app/reference/unleash-proxy)
and have a look at both the proxy docs and the Edge docs. Potentially
have a look at the SDK docs too to verify that everything still works.
2. Consider whether they think moving the proxy and edge docs up a level
(in the sidebar) makes sense.
3. Let me know what slug they'd prefer for the Edge docs. I've gone with
`unleash-edge` for now (so that it's
`docs.getunleash.io/reference/unleash-edge`), but we could potentially
also just use `edge`. WDYT?
4. Read through the detailed changes section.
5. Let me know if they have any other concerns or questions.
## Screenies
The new proxy doc:
The new edge doc:
2023-02-16 13:36:28 +01:00
|
|
|
],
|
|
|
|
|
themes: [
|
|
|
|
|
'docusaurus-theme-openapi-docs', // Allows use of @theme/ApiItem and other components
|
|
|
|
|
'@docusaurus/theme-mermaid',
|
2021-08-17 15:24:37 +02:00
|
|
|
],
|
2023-06-23 13:55:59 +02:00
|
|
|
scripts: [
|
|
|
|
|
{
|
|
|
|
|
src: 'https://widget.kapa.ai/kapa-widget.bundle.js',
|
|
|
|
|
'data-website-id': '1d187510-1726-4011-b0f7-62742ae064ee',
|
|
|
|
|
'data-project-name': 'Unleash',
|
|
|
|
|
'data-project-color': '#1A4049',
|
|
|
|
|
'data-project-logo':
|
|
|
|
|
'https://cdn.getunleash.io/uploads/2022/05/logo.png',
|
|
|
|
|
async: true,
|
|
|
|
|
},
|
|
|
|
|
],
|
2024-03-13 12:30:40 +01:00
|
|
|
clientModules: [require.resolve('./global.js')],
|
2021-06-04 11:17:15 +02:00
|
|
|
};
|
