Signed-off-by: andreas-unleash <andreas@getunleash.ai>
MakeStyles refactor 1-3
<!-- Thanks for creating a PR! To make it easier for reviewers and
everyone else to understand what your changes relate to, please add some
relevant content to the headings below. Feel free to ignore or delete
sections that you don't think are relevant. Thank you! ❤️ -->
## About the changes
<!-- Describe the changes introduced. What are they and why are they
being introduced? Feel free to also add screenshots or steps to view the
changes if they're visual. -->
<!-- Does it close an issue? Multiple? -->
Closes #
<!-- (For internal contributors): Does it relate to an issue on public
roadmap? -->
<!--
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#
-->
### Important files
<!-- PRs can contain a lot of changes, but not all changes are equally
important. Where should a reviewer start looking to get an overview of
the changes? Are any files particularly important? -->
## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
<!-- Thanks for creating a PR! To make it easier for reviewers and
everyone else to understand what your changes relate to, please add some
relevant content to the headings below. Feel free to ignore or delete
sections that you don't think are relevant. Thank you! ❤️ -->
ApiTokenForm refactoring
## About the changes
<!-- Describe the changes introduced. What are they and why are they
being introduced? Feel free to also add screenshots or steps to view the
changes if they're visual. -->
<!-- Does it close an issue? Multiple? -->
Closes #
<!-- (For internal contributors): Does it relate to an issue on public
roadmap? -->
<!--
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#
-->
### Important files
<!-- PRs can contain a lot of changes, but not all changes are equally
important. Where should a reviewer start looking to get an overview of
the changes? Are any files particularly important? -->
## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->
Signed-off-by: andreas-unleash <andreas@getunleash.ai>
Co-authored-by: andreas-unleash <andreas@getunleash.ai>
## 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.
## About the changes
According to our docs, we only support up to 1 decimal place for
weights. This is to use integers to represent the percentages (we divide
them by 10) and supporting more decimals results in bad maths due to
floating point arithmetics.
This PRs adds Frontend and Backend validations to enforce this
restriction
Closes#2222
## Discussion points
Should we reconsider supporting more decimal places, that door remains
open, but for now we'll just adhere to our documentation because that
change would require some development.
## About the changes
When exporting features one is normally also interested in disabled
features, so they are also included in the export file, while the
variants are not. I do not see a good reason for that, so this PR
removes the check and exports the variants then as well.
I could also add an option as well, but as long as there is no good
reason for ignoring the variants I would just export them with the
features.
This PR adds tests on #2719Closes#2719
Co-authored-by: Martin Joehren <martin.joehren@esailors.de>
# 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.
We have experienced side-effects where the import was unexpected and
resulted in environments thought to be removed. This had the unexpected
side-effect of also deleting API keys for some environments not part of
the import file.
This commit removes the ability of the state-service to mutate api keys
directly. There is no compelling reasons why we should remove API keys
as part of an import query.
Co-authored-by: Gastón Fournier <gaston@getunleash.ai>
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
## About the changes
To avoid showing too much data in the traffic screen, limit the number
of results to `topk`.
## Discussion points
Top 10 is a rule of thumb, but maybe we could do top 25. Until we gather
more data, I believe this should be good enough
## What
This change updates some places in the docs where we use the terms
"login" and "logout" incorrectly.
A "login" is a noun, typically referring to the set of credentials you
need to _log in_ to a service. The verb form, the act of signing in, is
written in two words: to "log in".
A similar logic applies to "logout" and "log out", although I don't find
the term "logout" in my dictionary. However, I think it makes sense to
talk about "logout requests" (and I see references to logout in other
services and documentation), so I'm happy to use that as a noun.
Regardless, the act of logging out is to "log out".
This change fixes some broken links in the "about the docs" document.
Most of these links go to concrete documents and have been replaced with
their appropriate relative file links. The few links that go to
auto-generated pages have been corrected.
Unfortunately, there does not seem to be an easy way to link safely to
generated pages.
## What
This change does two things:
It **removes the `environment` option** from the initialization
examples. This option is deprecated and only causes confusion. There's
no good reason to have it lying around in the examples.
It also **updates the explanation of the code samples**, telling you
that you need to generate an API key and linking you to the reference
doc and how to guide.
Relates to: #2782.
