1
0
mirror of https://github.com/Unleash/unleash.git synced 2024-12-22 19:07:54 +01:00
unleash.unleash/website/docusaurus.config.js

623 lines
23 KiB
JavaScript
Raw Normal View History

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. ![image](https://user-images.githubusercontent.com/17786332/210373446-784b7e69-0f36-4e9e-874a-2b06b863b603.png) # 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
const { readmes } = require('./readme-fns');
// 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),
};
};
/** @type {import('@docusaurus/types').DocusaurusConfig} */
module.exports = {
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',
favicon: 'img/favicon.ico',
organizationName: 'Unleash', // Usually your GitHub org/user name.
projectName: 'unleash.github.io', // Usually your repo name.
trailingSlash: false,
customFields: {
// expose env vars etc here
unleashProxyUrl: process.env.UNLEASH_PROXY_URL,
unleashProxyClientKey: process.env.UNLEASH_PROXY_CLIENT_KEY,
unleashFeedbackTargetUrl: process.env.UNLEASH_FEEDBACK_TARGET_URL,
environment: process.env.NODE_ENV,
},
themeConfig: {
defaultMode: 'light',
disableSwitch: true,
respectPrefersColorScheme: false,
2021-06-16 08:52:33 +02:00
algolia: {
appId: '5U05JI5NE1',
apiKey: 'dc9c4491fcf9143ee34015f22d1dd9d6',
indexName: 'getunleash',
2021-06-16 08:52:33 +02:00
},
navbar: {
title: 'Unleash',
logo: {
alt: 'Unleash logo',
src: 'img/logo.svg',
},
items: [
{
href: 'https://www.getunleash.io/plans',
label: 'Unleash Enterprise',
position: 'right',
},
{
href: 'https://github.com/Unleash/unleash',
position: 'right',
className: 'header-github-link',
'aria-label': 'Unleash GitHub repository',
},
],
},
2021-06-04 14:50:52 +02:00
prism: {
additionalLanguages: [
'csharp',
'dart',
'http',
'java',
'kotlin',
'php',
'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. ![image](https://user-images.githubusercontent.com/17786332/210373446-784b7e69-0f36-4e9e-874a-2b06b863b603.png) # 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',
'swift',
],
},
footer: {
style: 'dark',
links: [
{
title: 'Product',
items: [
{
label: 'Docs',
to: '/',
2021-08-11 12:55:56 +02:00
},
{
label: 'Unleash on GitHub',
href: 'https://github.com/Unleash/unleash',
2021-08-11 12:55:56 +02:00
},
{
label: 'Roadmap',
href: 'https://github.com/orgs/Unleash/projects/10',
},
{
label: 'Unleash help center',
href: 'https://getunleash.zendesk.com/hc/en-gb',
},
],
},
{
title: 'Community',
items: [
{
label: 'GitHub discussions',
href: 'https://github.com/unleash/unleash/discussions/',
},
{
label: 'Slack',
href: 'https://slack.unleash.run/',
},
{
label: 'Stack Overflow',
href: 'https://stackoverflow.com/questions/tagged/unleash',
},
{
label: 'Twitter',
href: 'https://twitter.com/getunleash',
},
],
},
],
copyright: `Copyright © ${new Date().getFullYear()} Unleash. Built with Docusaurus.`,
logo: {
src: 'img/logo.svg',
alt: 'Unleash logo',
},
},
image: 'img/logo.png',
},
presets: [
[
'@docusaurus/preset-classic',
{
docs: {
sidebarPath: require.resolve('./sidebars.js'),
// Please change this to your repo.
editUrl:
'https://github.com/Unleash/unleash/edit/main/website/',
routeBasePath: '/',
remarkPlugins: [
[
require('@docusaurus/remark-plugin-npm2yarn'),
{ sync: true },
],
],
docLayoutComponent: '@theme/DocPage',
docItemComponent: '@theme/ApiItem',
},
theme: {
customCss: require.resolve('./src/css/custom.css'),
},
googleAnalytics: {
trackingID: 'UA-134882379-1',
},
},
],
],
plugins: [
[
docs: update images using latest UI screenshots (#1992) * Update api_access_history.png * updating images in - How to capture impression data * Update Quickstart image * Update images: How to add strategy constraints * Update images: How to create a feature toggle * Update images: How to define custom context fields * Update images: How to use custom activation strategies * Update images: How to schedule feature releases * Update images: How to add new users to your Unleash instance * Update images: How to create and assign custom project roles * Update images: How to add SSO with OpenId Connect * Update images: How to add SSO with SAML 2.0 Okta * Update images: Slack * Update images: Activation Strategies * Update images: Archived toggles * Update images: The audit log * Update images: Impression data * Update images: Custom Activation Strategies * Update images: Environments * Update images: Feature Toggle Types * Update images: Feature Toggle Variants * Update images: Projects * Update images: Segments * Update images: Stickiness * Update images: Strategy Constraints * Update images: Technical Debt * Update images: Unleash Context * Update images: Unleash introductory overview * Update images: Unleash introductory overview * docs: replace strategy constraints step 2 img * Update website/docs/how-to/how-to-add-strategy-constraints.md Co-authored-by: Thomas Heartman <thomas@getunleash.ai> * change text request * Updating docs text to match the screenshots * Docs: change audit log to event log and add redirects * Docs: update "archive" page with deletion info * Docs: update constraints how to * Docs: minor tech debt doc fixes * docs-update-images-set1: update overview page * Apply suggestions from code review Co-authored-by: Thomas Heartman <thomas@getunleash.ai> * Update website/docs/user_guide/quickstart.md Co-authored-by: Thomas Heartman <thomas@getunleash.ai> * Update website/docs/user_guide/user-management.md Co-authored-by: Thomas Heartman <thomas@getunleash.ai> * Update website/docs/user_guide/user-management.md Co-authored-by: Thomas Heartman <thomas@getunleash.ai> * Activation strategy update * Apply suggestions from code review * Update delete-archive img * Fix prettier formatting for admonitions * Update website/docs/user_guide/environments.md * Update website/docs/user_guide/projects.md Co-authored-by: Tymoteusz Czech <tymek+gpg@getunleash.ai> Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
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/
'@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',
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-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
},
{
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',
},
{
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',
},
{
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',
},
{
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',
},
docs: update images using latest UI screenshots (#1992) * Update api_access_history.png * updating images in - How to capture impression data * Update Quickstart image * Update images: How to add strategy constraints * Update images: How to create a feature toggle * Update images: How to define custom context fields * Update images: How to use custom activation strategies * Update images: How to schedule feature releases * Update images: How to add new users to your Unleash instance * Update images: How to create and assign custom project roles * Update images: How to add SSO with OpenId Connect * Update images: How to add SSO with SAML 2.0 Okta * Update images: Slack * Update images: Activation Strategies * Update images: Archived toggles * Update images: The audit log * Update images: Impression data * Update images: Custom Activation Strategies * Update images: Environments * Update images: Feature Toggle Types * Update images: Feature Toggle Variants * Update images: Projects * Update images: Segments * Update images: Stickiness * Update images: Strategy Constraints * Update images: Technical Debt * Update images: Unleash Context * Update images: Unleash introductory overview * Update images: Unleash introductory overview * docs: replace strategy constraints step 2 img * Update website/docs/how-to/how-to-add-strategy-constraints.md Co-authored-by: Thomas Heartman <thomas@getunleash.ai> * change text request * Updating docs text to match the screenshots * Docs: change audit log to event log and add redirects * Docs: update "archive" page with deletion info * Docs: update constraints how to * Docs: minor tech debt doc fixes * docs-update-images-set1: update overview page * Apply suggestions from code review Co-authored-by: Thomas Heartman <thomas@getunleash.ai> * Update website/docs/user_guide/quickstart.md Co-authored-by: Thomas Heartman <thomas@getunleash.ai> * Update website/docs/user_guide/user-management.md Co-authored-by: Thomas Heartman <thomas@getunleash.ai> * Update website/docs/user_guide/user-management.md Co-authored-by: Thomas Heartman <thomas@getunleash.ai> * Activation strategy update * Apply suggestions from code review * Update delete-archive img * Fix prettier formatting for admonitions * Update website/docs/user_guide/environments.md * Update website/docs/user_guide/projects.md Co-authored-by: Tymoteusz Czech <tymek+gpg@getunleash.ai> Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
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',
'/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',
docs: update images using latest UI screenshots (#1992) * Update api_access_history.png * updating images in - How to capture impression data * Update Quickstart image * Update images: How to add strategy constraints * Update images: How to create a feature toggle * Update images: How to define custom context fields * Update images: How to use custom activation strategies * Update images: How to schedule feature releases * Update images: How to add new users to your Unleash instance * Update images: How to create and assign custom project roles * Update images: How to add SSO with OpenId Connect * Update images: How to add SSO with SAML 2.0 Okta * Update images: Slack * Update images: Activation Strategies * Update images: Archived toggles * Update images: The audit log * Update images: Impression data * Update images: Custom Activation Strategies * Update images: Environments * Update images: Feature Toggle Types * Update images: Feature Toggle Variants * Update images: Projects * Update images: Segments * Update images: Stickiness * Update images: Strategy Constraints * Update images: Technical Debt * Update images: Unleash Context * Update images: Unleash introductory overview * Update images: Unleash introductory overview * docs: replace strategy constraints step 2 img * Update website/docs/how-to/how-to-add-strategy-constraints.md Co-authored-by: Thomas Heartman <thomas@getunleash.ai> * change text request * Updating docs text to match the screenshots * Docs: change audit log to event log and add redirects * Docs: update "archive" page with deletion info * Docs: update constraints how to * Docs: minor tech debt doc fixes * docs-update-images-set1: update overview page * Apply suggestions from code review Co-authored-by: Thomas Heartman <thomas@getunleash.ai> * Update website/docs/user_guide/quickstart.md Co-authored-by: Thomas Heartman <thomas@getunleash.ai> * Update website/docs/user_guide/user-management.md Co-authored-by: Thomas Heartman <thomas@getunleash.ai> * Update website/docs/user_guide/user-management.md Co-authored-by: Thomas Heartman <thomas@getunleash.ai> * Activation strategy update * Apply suggestions from code review * Update delete-archive img * Fix prettier formatting for admonitions * Update website/docs/user_guide/environments.md * Update website/docs/user_guide/projects.md Co-authored-by: Tymoteusz Czech <tymek+gpg@getunleash.ai> Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
2022-09-14 09:59:18 +02:00
},
docs: Remove/update references to Heroku (#2099) ## What This PR removes or updates references in the docs to Heroku. Most of the code samples have been replaced with a more generic `unleash.example.com` url, while other references have been removed or updated. Also removes old OpenAPI files that are out of date and redundant with the new generation. ## Background Come November and Heroku will no longer offer free deployments of Unleash, so it's about time we remove that claim. Links to the heroku instance are also outdated because we don't have that instance running anymore. Finally, the OpenAPI files we do have there are old and static, so they don't match the current reality. ## Commits * Meta: update ignore file to ignore autogenerated docs I must've missed the ignore file when looking for patterns. * docs: delete old openapi file. This seems to have been a holdover from 2020 and is probably hand-written. It has been superseded by the new autogenerated OpenAPI docs. * docs: add notes for heroku changes to the frontend readme and pkg * docs: remove old openapi article and add redirects to new openapi * docs: fix link in overview doc: point to GitHub instead of heroku * docs: update quickstart docs with new heroku details * docs: remove reference to crashing heroku instance * docs: remove references to herokuapp in code samples * docs: add a placeholder comment * docs: update references for heroku updates * docs: keep using unleash4 for enterprise * docs: remove start:heroku script in favor of start:sandbox * docs: remove 'deploy on heroku button' Now that it's not free anymore (or won't be very shortly), let's remove it. * docs: remove extra newline
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',
docs: Remove/update references to Heroku (#2099) ## What This PR removes or updates references in the docs to Heroku. Most of the code samples have been replaced with a more generic `unleash.example.com` url, while other references have been removed or updated. Also removes old OpenAPI files that are out of date and redundant with the new generation. ## Background Come November and Heroku will no longer offer free deployments of Unleash, so it's about time we remove that claim. Links to the heroku instance are also outdated because we don't have that instance running anymore. Finally, the OpenAPI files we do have there are old and static, so they don't match the current reality. ## Commits * Meta: update ignore file to ignore autogenerated docs I must've missed the ignore file when looking for patterns. * docs: delete old openapi file. This seems to have been a holdover from 2020 and is probably hand-written. It has been superseded by the new autogenerated OpenAPI docs. * docs: add notes for heroku changes to the frontend readme and pkg * docs: remove old openapi article and add redirects to new openapi * docs: fix link in overview doc: point to GitHub instead of heroku * docs: update quickstart docs with new heroku details * docs: remove reference to crashing heroku instance * docs: remove references to herokuapp in code samples * docs: add a placeholder comment * docs: update references for heroku updates * docs: keep using unleash4 for enterprise * docs: remove start:heroku script in favor of start:sandbox * docs: remove 'deploy on heroku button' Now that it's not free anymore (or won't be very shortly), let's remove it. * docs: remove extra newline
2022-10-19 14:02:00 +02: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',
},
{
from: '/deploy',
to: '/reference/deploy',
},
{
from: '/deploy/getting_started',
to: '/reference/deploy/getting-started',
},
{
from: '/deploy/configuring_unleash',
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/deploy/configuring-unleash',
},
{
from: '/deploy/configuring_unleash_v3',
to: '/reference/deploy/configuring-unleash-v3',
},
{
from: '/deploy/database-setup',
to: '/reference/deploy/database-setup',
},
{
from: '/deploy/database_backup',
to: '/reference/deploy/database-backup',
},
{
from: '/deploy/email',
to: '/reference/deploy/email-service',
},
{
from: '/deploy/google_auth_v3',
to: '/reference/deploy/google-auth-v3',
},
{
from: '/deploy/google_auth',
to: '/reference/deploy/google-auth-hook',
},
{
from: '/deploy/import_export',
to: '/reference/deploy/import-export',
},
{
from: '/deploy/migration_guide',
to: '/reference/deploy/migration-guide',
},
{
from: '/deploy/securing_unleash',
to: '/reference/deploy/securing-unleash',
},
{
from: '/deploy/securing-unleash-v3',
to: '/reference/deploy/securing-unleash-v3',
},
{
from: '/addons',
to: '/reference/addons',
},
{
from: '/addons/datadog',
to: '/reference/addons/datadog',
},
{
from: '/addons/slack',
to: '/reference/addons/slack',
},
{
from: '/addons/teams',
to: '/reference/addons/teams',
},
{
from: '/addons/webhook',
to: '/reference/addons/webhook',
},
{
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',
},
{
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',
},
{
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',
},
{
from: '/user_guide/rbac',
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',
},
{
from: '/user_guide/important-concepts',
to: '/tutorials/important-concepts',
},
{
from: [
'/user_guide/quickstart',
'/docs/getting_started',
],
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: '/tutorials/quickstart',
},
{
from: '/user_guide/unleash_overview',
to: '/tutorials/unleash-overview',
},
{
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',
},
{
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',
},
{
from: '/help',
to: '/',
},
].map(addDocsRoutePrefix), // add /docs prefixes
createRedirects: function (toPath) {
if (
toPath.indexOf('/docs/') === -1 &&
toPath.indexOf('index.html') === -1
) {
return `/docs/${toPath}`;
}
},
},
],
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:
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. ![image](https://user-images.githubusercontent.com/17786332/210373446-784b7e69-0f36-4e9e-874a-2b06b863b603.png) # 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
docs: auto-generate remaining server-side SDK docs (#2858) This PR builds on the preceding doc auto-generation PRs and generates documentation for the remaining server-side SDKs. ## Why Refer to https://github.com/Unleash/unleash/pull/2809 for more context about generating SDK docs. ## What - Adds generation for the remaining server-side SDKs - Moves generated docs from the `/reference/sdks` directory to `/generated` directory. - Makes sure that the URLs do not change because of the move by using the `slug` frontmatter property. - replaces relative github links in the markdown documents so that they become absolute github links. (refer to the next section) - Updates some image styling so that it doesn't apply to readme badges (we don't need them using `display: block`) ### On link replacing: This PR adds handling of links in the generated documentation. Specifically, it changes links in one case: Relative links to github. Links to code and other files in the repository. These are prefixed with the repository's URL. While this should work in most cases, it will fail in cases where the links to the files are not on the repository's primary branch. (typically main, but could also be "v3", for instance). In these cases, the links will get a double branch in the URL and will fail. However, I see no easy way around this (though suggestions are definitely accepted!), and think it's a fair tradeoff. It takes the links from "definitely failing" to "will work in the vast majority of cases". Note: I originally also wanted to handle the case where the link is an absolute link to docs.getunleash.io. We could turn these into relative urls to avoid full page reloads and enjoy a smoother experience. However, the client-side redirects don't work correctly if the relative URL goes to a redirect page, so you end up with a 404 page. As such, I think it's better to leave the links as absolute for now.
2023-01-13 12:40:28 +01:00
outDir: 'docs/generated/sdks', // the base directory to output to.
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. ![image](https://user-images.githubusercontent.com/17786332/210373446-784b7e69-0f36-4e9e-874a-2b06b863b603.png) # 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
documents: readmes.documentUrls, // the file names to download
modifyContent: readmes.modifyContent,
},
],
],
themes: ['docusaurus-theme-openapi-docs'], // Allows use of @theme/ApiItem and other components
};