Upgrading to 5.7 and above from earlier versions is a little
problematic. Let's document it.
---------
Co-authored-by: Gastón Fournier <gaston@getunleash.io>
## About the changes
When edge is configured to automatically generate tokens, it requires
the token to be present in all unleash instances.
It's behind a flag which enables us to turn it on on a case by case
scenario.
The risk of this implementation is that we'd be adding load to the
database in the middleware that evaluates tokens (which are present in
mostly all our API calls. We only query when the token is missing but
because the /client and /frontend endpoints which will be the affected
ones are high throughput, we want to be extra careful to avoid DDoSing
ourselves
## Alternatives:
One alternative would be that we merge the two endpoints into one.
Currently, Edge does the following:
If the token is not valid, it tries to create a token using a service
account token and /api/admin/create-token endpoint. Then it uses the
token generated (which is returned from the prior endpoint) to query
/api/frontend. What if we could call /api/frontend with the same service
account we use to create the token? It may sound risky but if the same
application holding the service account token with permission to create
a token, can call /api/frontend via the generated token, shouldn't it be
able to call the endpoint directly?
The purpose of the token is authentication and authorization. With the
two tokens we are authenticating the same app with 2 different
authorization scopes, but because it's the same app we are
authenticating, can't we just use one token and assume that the app has
both scopes?
If the service account already has permissions to create a token and
then use that token for further actions, allowing it to directly call
/api/frontend does not necessarily introduce new security risks. The
only risk is allowing the app to generate new tokens. Which leads to the
third alternative: should we just remove this option from edge?
<!-- 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. -->
A v1 Java tutorial for docs! I used Java SDK to log flag statuses when
the Java app is running and connected to Unleash.
## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->
It's fairly simple and open to feedback for a new iteration to improve
the intro tutorial. I do weekly documentation improvement PRs!
I've held an internal knowledge sharing session on this already. If
someone can think of a better phrasing for the background, I'm all ears.
I think it's just nice to have this documented, so people remember that
our logging framework already has a good way to format errors when you
use the API `logger.error("<message>", e)`
Fixes ##5799 and #5785
When you do not provide a token we should resolve to the "default"
environment to maintain backward compatibility. If you actually provide
a token we should prefer that and even block the request if it is not
valid.
An interesting fact is that "default" environment is not available on a
fresh installation of Unleash. This means that you need to provide a
token to actually get access to toggle configurations.
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
Having old ADRs makes it harder for newcomers, that have to navigate
through many ADRs and spot the ones that were superseded by others. We
can save the mental burden by just moving the old ones to a deprecated
folder
This change updates the change request scheduling docs to include
information about what happens when a strategy or segment is updated
in the background, as well as updated information about the emails
that it sends out.
This PR updates the images in the feature flags best practices guide to
work on dark backgrounds by giving them white backgrounds (making them
non-transparent).
In doing so, it replaces the links to GitHub with docusaurus assets
(which also yields faster loading) and uses captions to describe the
images.
So we have a place in the docs to refer users struggling with getting
metrics from Edge after upgrade to Unleash v5.9.0, this PR adds a small
troubleshooting note about two fixes.
1. Upgrade Edge
2. Use environmental flag to re-enable old endpoint
<!-- 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. -->
A new Python Examples doc:
- underneath Python tutorials
- explores more use cases for Python with feature flags in Unleash,
building on top of our existing Python tutorial.
- This was edited and reviewed by team members via [Google
Docs](https://docs.google.com/document/d/1gO5KSShCKObbdjP-TobIjaOLqTP5_V1YcTLXAp5DA2g/edit#heading=h.oblpm3ljyzs8)
before adding to our docs site.
- Python Tutorial links to this doc as a continuation
<img width="1502" alt="Screenshot 2024-01-31 at 11 44 28 AM"
src="https://github.com/Unleash/unleash/assets/22972707/86aec6a5-9483-41a8-bd65-ae0fcf7d7c7f">
<!-- 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? -->
`website/docs/feature-flag-tutorials/python/examples.md`
## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->
---------
Co-authored-by: Nuno Góis <github@nunogois.com>
<!-- 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. -->
- Reducing the amount of steps to implement the Python app feature flag
- fixed spaces & indentations in Python code snippets (mentioned in past
PR review)
- `git clone` my forked repo so we can customize that code in the future
as we improve it, without being blocked.
<!-- 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? -->
More improvements to be made to the HTTP calls in `routes.py` as I
continue working on resolving some issues I'm running into in the app.
---------
Co-authored-by: Simon Hornby <liquidwicked64@gmail.com>
## Key Updates in the ADR
- **Separation of Migrations in PRs**: Migrations are now required to be
carried out in separate pull requests. This change is intended to
improve the monitoring and management of database schema changes during
deployment.
- **Primary Key Requirement for New Tables**: A new paragraph mandates
the inclusion of primary keys in all new tables, emphasizing the
importance of data integrity, efficient data retrieval, and supporting
table relationships. Additionally, by adding primary keys, we resolve
the issue of migrations failing during upgrades in replicated database
setups, as we are not using PostgreSQL replica identities. Exceptions to
this rule require a compelling justification.
Also added better structuring and styling to ADR for better readability.
<!-- 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. -->
- Simplified wording
- More descriptive ALT text for images
- Included YouTube tutorial link
- Improve code indentation in some code blocks
<!-- (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? -->
YouTube link at the top of a tutorial or near the bottom?
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
<!-- 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. -->
Let's update our tutorial titles in the left navigation menu so it's
shorter and simpler.
This will _not_ change the metadata and doc titles when you click on
them. Only the label in the nav.
BEFORE
AFTER
<!-- 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? -->
<!-- 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. -->
A new tutorial to get developers to implement feature flags into a
Python Flask app.
We have steps that guide them through the process using a simple
full-stack survey app.
Based off of a reviewed [Google Doc
here](https://docs.google.com/document/d/1YlG-TyQcMEyUrMjiWlYrd-J5DXog5ErbvSKAyuzKAnU/edit#heading=h.ryvmv14764i3)
The tutorial can go live in the docs nav in a new Python section, where
the Python examples will follow.
### 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? -->
`website/docs/feature-flag-tutorials/python/implementing-feature-flags.md`
## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->
---------
Co-authored-by: Simon Hornby <liquidwicked64@gmail.com>
<!-- 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. -->
This is a demo that uses [Floe](https://www.floe.dev/) to review the
`how-to` directory using the `spelling-and-grammar` rule.
You can read more about the tool here: https://www.floe.dev/docs
New docs page for the beta license keys feature introduced in Unleash
5.8 for self-hosted enterprise users.
---------
Co-authored-by: Ivar Conradi Østhus <ivar@getunleash.io>
<!-- 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. -->
This is a large PR with all of the React examples building on top of the
original tutorial.
Based off of this Google Doc:
https://docs.google.com/document/d/1m3ujgyrkJTCGLsEsBr1_eq4HQKqsf-lfvGFDJobns44/edit
I also included updates to the React tutorial links so they are relative
paths, not full URL paths.
I propose we make fast-follow updates to this piece of documentation for
changes we need to make in order to release and iterate on minor
updates.
### 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? -->
website/docs/feature-flag-tutorials/react/examples.md
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
We want to deprecate and eventually remove the option for admin tokens.
This PR updates the docs to inform readers about the deprecation as well
as recommending what they can use instead.
This PR describes in closer detail what happens when the user who
scheduled a change request is deleted. It mentions the new suspended
state and what the user can do to get out of it.
This change adds a mention of frontend API tokens to the docs. We've
had this functionality for a while, but it appears not to have been
documented.
Realized this as part of triaging #3005.
This commit updates the change request docs to talk about how the new
scheduled state works.
The subsection is marked as "in development", saying that it can
change at any moment until the feature is released.
<!-- 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. -->
We've made some first round updates to the React tutorial:
- making it more SEO-friendly with ordered lists, sequential language,
description of the JS library
- Switched over the demo app to point to an open source project:
[Cypress Real World
App](https://github.com/cypress-io/cypress-realworld-app)
- included best practice considerations for client-side development
- updated URL path to point to `/feature-flag-tutorials/react` for
simplification
## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->
Would love feedback on if there's a need for more screenshots? Don't
want to be too screenshot-heavy though I imagine.
And need feedback on the descriptions of "Considerations for using
feature flags in react"
https://github.com/Unleash/unleash/compare/react-improvements?expand=1#diff-96d4956f49f80cd76489a72d4d88c2956ce9dcc695f66fe014ad1185e37cb589R21
Want to make sure that what I described makes sense or if it could use
some tweaking to convey the right message clearly.
## Why
Currently AWS API Gateway doesn't have compression enabled by default,
this PR will make it easier to for example deploy Unleash over to AWS
Lambda without further configuration in API Gateway, frameworks like
Serverless requires a bit more work to set up compression and some times
one might not need compression at all.
## How
Create a new config flag called `disableCompression` which will not
include `compression` middleware in express' instance when set as true.
A benefit of hosting your own edge instance is that it will be as close
to end users as you are.
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
Adding links to definition of what frontend api is. Can be confusing for
new users to read without seing what it is.
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
## About the changes
Adding in an initial React tutorial with Unleash! This includes
installing Unleash, creating a React application with Vite, then
integrating Unleash to use with a CSS-focused feature toggle.
### Important files
- New File:
`website/docs/feature-flag-tutorials/react/implementing-feature-flags.md`
- Added new tutorial to navigation in `sidebars.js` and
`docusaurus.config.js`
There is a lot of room to make more advanced use case additions to this
React tutorial. For example, addressing SSR.
I think that'd be good for a future iteration to be helpful to the
community.
As discovered in the recent segments breakathon, the docs aren't very
clear about how conflicts are handled. This PR better documents when
they can't be deleted or moved. It also mentions the edge case where a
segment is used in an archived flag (it still can't be deleted, so you
must either delete the flag, or revive it and remove the segment)
https://linear.app/unleash/issue/2-1680/adr-specify-tables-when-querying-columns
This PR includes my suggestion of a "Specificity in database column
references" ADR.
The ADR proposes a standard for explicitly specifying the full table
name or alias for each column in our SQL queries, especially for queries
with joins between multiple tables. This decision is a direct response
to recent ambiguity errors encountered due to a database migration,
emphasizing the need for clearer SQL query standards in complex joins
and schema changes.
---------
Co-authored-by: Mateusz Kwasniewski <kwasniewski.mateusz@gmail.com>
See [Linear issue
2-1627](https://linear.app/unleash/issue/2-1627/db-permissions-update-docs-and-migration-guides).
Since we now use functions, we need more permissions than just GRANT ALL
PERMISSIONS ON DATBASE. In addition we need to be allowed to create
functions in the schema that's actually being used. This PR takes the
easy way out and say that we need OWNER privileges on the database. That
guarantees that we can do all we do in our migration scripts.
### Discussion points
We might encounter some pushback on this, if so, we'll need to say that
we need
`GRANT ALL PRIVILEGES ON ALL FUNCTIONS IN <schema>` in addition to GRANT
ALL PRIVILEGES ON DATABASE, where <schema> is the schema selected in
their configuration.
We've been caught out here, we added a migration that used PG>=11
syntax, but our docs still state that we support v10, when it reached
EoL Nov 2022. This updates our docs to state v14 and newer, v14 came out
in 2021 and as such won't be EoL until 2026 according to [Postgres 5
year versioning scheme
support](https://www.postgresql.org/support/versioning/)
## About the changes
While working on Terraform I identified some issues with how our backend
handled some requests. This happened because the Terraform client was
unaware of new fields and was not sending them. This resulted in bad
behavior as some of those missing fields were treated in the backend as
`null` and removed existing data from the DB.
This ADR aims to shed some light on the problem and specifies how our
server should handle these requests.
---------
Co-authored-by: Nuno Góis <github@nunogois.com>
- Adding a new image to indicate that you also need to save the strategy
after you add a constraint
- Adding a new image showing how the edit constraint section looks like
- Update a bit the text to match the new images
Added a detailed explanation into how frontend / client-side SDKs behave
with regards to fetching multiple feature flags and network
connectivity.
Content has been reviewed/approved by engineering rotation team (Simon
and Chris).
## About the changes
Refactor the main nav, with the following goals:
* Communicate the value of each section vs the format (ex:
“Understanding Unleash” vs “Topic Guides”)
* Make space for the Feature Flag tutorials section that we’re starting
to build
* Scope updates to navigation and pages that need updates based on new
URLs & organization
* Update URLs to follow the new hierarchy without breaking links (adding
redirects & editing internal links between pages as needed)
### Important files
sidebar.js
docusaurus.config.js
## Discussion points
* Redirects can't be tested out of prod, which is a bummer :/
* Some URLs have been preserved untouched while we monitor for potential
negative SEO impact of client-side redirects
* It's a large PR (sorry). Nav changes and file movements impacted lots
of files.
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
### What
This PR makes the rate limit for user creation and simple login (our
password based login) configurable in the same way you can do
metricsRateLimiting.
### Worth noting
In addition this PR adds a `rate_limit{endpoint, method}` prometheus
gauge, which gets the data from the UnleashConfig.
### What
The heaviest requests we serve are the register and metrics POSTs from
our SDKs/clients.
This PR adds ratelimiting to /api/client/register, /api/client/metrics,
/api/frontend/register and /api/frontend/metrics with a default set to
6000 requests per minute (or 100 rps) for each of the endpoints.
It will be overrideable by the environment variables documented.
### Points of discussion
@kwasniew already suggested using featuretoggles with variants to
control the rate per clientId. I struggled to see if we could
dynamically update the middleware after initialisation, so this attempt
will need a restart of the pod to update the request limit.
PR contains the following:
1) New video embeds for the following docs:
- website/docs/reference/deploy/environment-import-export.mdx
- website/docs/reference/playground.mdx
- website/docs/reference/strategy-constraints.md
- website/docs/topics/a-b-testing.md
2) Improvements to the Academy course playlist embedding for the three
Academy courses. Tested the standard method of embedding video, and it
seems this works well for playlists too.
Switching to the native Docusaurus embed solves the issue with dynamic
resizing. Rather than a static embed size the video will now scale to
the browser window size.
<!-- 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? -->
---------
Co-authored-by: Drew Gorton <dgorton@users.noreply.github.com>
Co-authored-by: Mark Fulton <128738155+markunl@users.noreply.github.com>
Adds a small troubleshooting guide for Unleash features availability.
This is not specific to features that have a visual component in the
admin UI, but that's the most common scenario.
https://linear.app/unleash/issue/2-1253/add-support-for-more-events-in-the-slack-app-integration
Adds support for a lot more events in our integrations. Here is how the
full list looks like:
- ADDON_CONFIG_CREATED
- ADDON_CONFIG_DELETED
- ADDON_CONFIG_UPDATED
- API_TOKEN_CREATED
- API_TOKEN_DELETED
- CHANGE_ADDED
- CHANGE_DISCARDED
- CHANGE_EDITED
- CHANGE_REQUEST_APPLIED
- CHANGE_REQUEST_APPROVAL_ADDED
- CHANGE_REQUEST_APPROVED
- CHANGE_REQUEST_CANCELLED
- CHANGE_REQUEST_CREATED
- CHANGE_REQUEST_DISCARDED
- CHANGE_REQUEST_REJECTED
- CHANGE_REQUEST_SENT_TO_REVIEW
- CONTEXT_FIELD_CREATED
- CONTEXT_FIELD_DELETED
- CONTEXT_FIELD_UPDATED
- FEATURE_ARCHIVED
- FEATURE_CREATED
- FEATURE_DELETED
- FEATURE_ENVIRONMENT_DISABLED
- FEATURE_ENVIRONMENT_ENABLED
- FEATURE_ENVIRONMENT_VARIANTS_UPDATED
- FEATURE_METADATA_UPDATED
- FEATURE_POTENTIALLY_STALE_ON
- FEATURE_PROJECT_CHANGE
- FEATURE_REVIVED
- FEATURE_STALE_OFF
- FEATURE_STALE_ON
- FEATURE_STRATEGY_ADD
- FEATURE_STRATEGY_REMOVE
- FEATURE_STRATEGY_UPDATE
- FEATURE_TAGGED
- FEATURE_UNTAGGED
- GROUP_CREATED
- GROUP_DELETED
- GROUP_UPDATED
- PROJECT_CREATED
- PROJECT_DELETED
- SEGMENT_CREATED
- SEGMENT_DELETED
- SEGMENT_UPDATED
- SERVICE_ACCOUNT_CREATED
- SERVICE_ACCOUNT_DELETED
- SERVICE_ACCOUNT_UPDATED
- USER_CREATED
- USER_DELETED
- USER_UPDATED
I added the events that I thought were relevant based on my own
discretion. Know of any event we should add? Let me know and I'll add it
🙂
For now I only added these events to the new Slack App integration, but
we can add them to the other integrations as well since they are now
supported.
The event formatter was refactored and changed quite a bit in order to
make it easier to maintain and add new events in the future. As a
result, events are now posted with different text. Do we consider this a
breaking change? If so, I can keep the old event formatter around,
create a new one and only use it for the new Slack App integration.
I noticed we don't have good 404 behaviors in the UI for things that are
deleted in the meantime, that's why I avoided some links to specific
resources (like feature strategies, integration configurations, etc),
but we could add them later if we improve this.
This PR also tries to add some consistency to the the way we log events.
## About the changes
Improvement to the description of the datadog integration. Adds 2
missing event types, removes an event type that is deprecated and about
to be completely removed, adds missing description of extra json headers
and source type name, and adds description for the new configuration
option for JSON body support
---------
Co-authored-by: Nuno Góis <github@nunogois.com>
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
https://linear.app/unleash/issue/2-1235/docs-slack-app-integration-documentation
This adds a new reference doc for the new Unleash Slack App integration
and marks the previous Slack integration as deprecated.
As a side-effect this PR also fixes an issue where we wouldn't be able
to delete tags with special characters.
---------
Co-authored-by: David Leek <david@getunleash.io>
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
I'm adding a Feature Flag Migration tutorial written by Customer Success
to the docs.
The content should live in the Topic Guide section
Topic Guides
Feature Flags Migration Best Practices index page with subpages for
* Define scope
* Make business case
* Planning
* Execution
* Onboarding users
---------
Co-authored-by: Thomas Heartman <thomasheartman+github@gmail.com>
Co-authored-by: Gastón Fournier <gastonfournier@gmail.com>
Co-authored-by: Gastón Fournier <gaston@getunleash.io>
Co-authored-by: Mark Fulton <128738155+markunl@users.noreply.github.com>
Co-authored-by: Thomas Heartman <thomas@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! ❤️ -->
## 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? -->
---------
Co-authored-by: Ivar Conradi Østhus <ivar@getunleash.io>
## About the changes
While exploring the [About the docs](https://docs.getunleash.io) page
for the first time, I observed the first bulleted list started with
lowercase, which isn't consistent with other sections of the page. This
minor PR capitalizes the first letter of the bullet lists in the
"Documentation structure" section. This ensures the list follows the
existing style across the page and the stable rule of written language
([reference](https://www.purchase.edu/editorial-style-guide/general-style-preferences/punctuation/bulleted-and-numbered-lists/#C)).
We love all open-source Unleash users. in 2022 we built the [segment
capability](https://docs.getunleash.io/reference/segments) (v4.13) as an
enterprise feature, simplify life for our customers.
Now it is time to contribute it to the world 🌏
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
This PR replaces references to _addons_ in the docs with references to
_integrations_.
In doing so, I have also:
- moved `/reference/addons` documents into `/reference/integrations`
- combined the previous "Addons" and "Integrations" categories into a
new "Integrations" category
- added redirects from all the old addons pages to their new locations
I have updated the wording, but have not changed things such as API
paths, event names, etc, because these will not change at the moment
(maybe a breaking change to schedule for v6?).
---------
Co-authored-by: Tymoteusz Czech <2625371+Tymek@users.noreply.github.com>
Fix issues uncovered when reviewing integrations list and form.
- YouTube CSP
- Text content and formatting
- Margins
- Update old integration icons
- Fix headers in dark theme
https://linear.app/unleash/issue/2-1130/documentation-about-multiple-project-roles
- Adds a section for the feature in the "Role-based Access control"
reference doc;
- Removes the mention that "Groups that *do* have a root role can't be
assigned to a project." which is no longer true;
- Adds a reference to multiple project roles in the "How to create and
assign custom project roles" guide;
- Fixes a wrong sentence in the "Assigning custom project roles" section
of the aforementioned guide;
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
## About the changes
Adds troubleshooting guides for some common problems under the how-to
area (following the [diataxis framework](https://diataxis.fr/)).
This is part of Unleash 2023 offsite challenge
---------
Co-authored-by: Drew Gorton <drew.gorton@getunleash.io>
Co-authored-by: Diego Susa <diego@getunleash.io>
Co-authored-by: Michael Vittiglio <michael.vittiglio@getunleash.io>
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
Introduce 'Feature Flag' language and replace most instances of 'Feature
Toggle'
<!-- 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
Introduce 'Feature Flag' language and replace most instances of 'toggle'
with 'flag' on Quickstart
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
https://linear.app/unleash/issue/2-1136/custom-root-roles-documentation
- [Adds documentation referencing custom root
roles](https://unleash-docs-git-docs-custom-root-roles-unleash-team.vercel.app/reference/rbac);
- [Adds a "How to create and assign custom root roles" how-to
guide](https://unleash-docs-git-docs-custom-root-roles-unleash-team.vercel.app/how-to/how-to-create-and-assign-custom-root-roles);
- Standardizes "global" roles to "root" roles;
- Standardizes "standard" roles to "predefined" roles to better reflect
their behavior and what is shown in our UI;
- Updates predefined role descriptions and makes them consistent;
- Updates the side panel description of the user form;
- Includes some boy scouting with some tiny fixes of things identified
along the way (e.g. the role form was persisting old data when closed
and re-opened);
Questions:
- Is it worth expanding the "Assigning custom root roles" section in the
"How to create and assign custom root roles" guide to include the steps
for assigning a root role for each entity (user, service account,
group)?
- Should this PR include an update to the existing "How to create and
assign custom project roles" guide? We've since updated the UI;
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
This change updates the existing feature toggle types document to add
a new `expected lifetime` section. This section explains better what
lifetimes are, where they come from, and that admins can (soon) change
the expected lifetimes for feature toggles.
This change updates the playground reference docs with some new images
and an explanation of how the results work now.
I have not removed any of the old images because I think they still
illustrate well how the playground works. And because they're not
direct screenshots anyway, that sounds like a fair trade-off to me.
Highlight edge in the first paragraph.
Not sure if we should suggest that it should be the preferred choice,
but at least this helps to realize there's an alternative already in the
first paragraph.
## About the changes
Custom activation strategies are still the recommended way to go in our
documentation, but now most of the use cases for custom activation
strategies can be covered by strategy constraints (released with Unleash
4.16)
With this change, we try to drive people to use strategy constraints.
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
### What
We had a customer wonder why `/api/proxy/development` wasn't configured
for them. After some digging it was found that they'd followed our
documentation and assumed that the proxy was configured for them.
However, since we no longer host proxies, this was not the case. This PR
updates the documentation to point out that "Unleash hosts everything"
now means that our clients should use Frontend API keys and the
`/api/frontend` endpoint to get what they used to get from embedded
proxies.
## Missing
We should make a new illustration in the same vein as the other
illustrations on this page to demonstrate what the Frontend API really
is. This PR removes the reference to the picture of the topology of
having Unleash hosting proxies.
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
Included a library from the ColdBox Open Source team.
More detail here if needed.
https://forgebox.io/view/unleashsdk
I cheated on the grammar. Grammarly helps me out there.
Hi! Adding a link to a some-batteries-included Haskell Unleash SDK. It
uses a "core" library underneath that adheres to your [Client
Specifications](https://github.com/Unleash/client-specification). Could
add a link to that too, but from what I can tell, it's overlapped by
your Yggdrasil project. We have been using the SDK for a handful of
months now and we're happy with how it works. Hope you'll have it :)
Co-authored-by: Even Brenden <evenbrenden@users.noreply.github.com>
<!-- 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! ❤️ -->
Documenting Default Strategy
## 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 #
[1-1023](https://linear.app/unleash/issue/1-1023/document-strategy-improvements)
<!-- (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: Thomas Heartman <thomas@getunleash.ai>
As requested in
[Linear](https://linear.app/unleash/issue/2-1147/unleash-cloud-make-keepalive-configurable)
this PR makes the serverKeepAliveTimeout configurable via the
SERVER_KEEPALIVE_TIMEOUT environment variable. This was already
configurable when starting Unleash programmatically, but it's nice to
have as an env variable as well
<!-- 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>
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
https://linear.app/unleash/issue/2-943/adr-separate-request-and-response-types-in-apis
During the updating of our OpenAPI documentation, we've seen several
times that our schemas are either way too wide for a response or way to
strict for a request. This is usually due to us reusing the same schema
for both request and response. We should write an ADR where we reason
about the usefulness of code duplication and keeping separate response
and request schemas.
Based on our needs, this PR adds my suggested ADR.
---------
Co-authored-by: Simon Hornby <liquidwicked64@gmail.com>
## About the changes
Added Azure SSO SAML 2.0 instructions based off of testing/user
feedback.
<!-- Does it close an issue? Multiple? -->
Not on GH, internally yes
### Important files
website>docs>how-to>how-to-add-sso-azure-saml.md
website>docs>static>img (added images for docs)
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Co-authored-by: sighphyre <liquidwicked64@gmail.com>
This adds documentation to the RBAC section on how to use root roles on
groups and updates a few screenshots for the group pages.
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
# Simplify package scripts
This PR's purpose is to raise a discussion surrounding our current
package scripts.
It includes some suggestions that aim to simplify the scripts and
hopefully bring a much more straightforward approach to developing and
contributing to Unleash.
Building (prod) should only happen **explicitly** and when needed.
## Before PR (current behavior)
- Clone the project;
- Open 2 terminals: One for `unleash` and another for
`unleash/frontend`;
- On `unleash`:
- Run `yarn` (which will also build, for some reason?);
- Run `yarn start:dev` to start backend in dev mode (`tsc-watch`);
- On `unleash/frontend`:
- Run `yarn` (which will also build, for some reason?);
- Run `yarn start` to start frontend in dev mode (`vite`);
So it seems to me like we build unnecessarily every time we install
dependencies. Neither dev scripts need to build the project, as backend
uses `tsc-watch` and frontend uses `vite`. I'm unsure why this is the
case, as building can take a very long time.
There's also some complexity in the way we need to split the terminal to
`cd` into `frontend` and treat it as a different project. The fact that
we have different script names is also confusing (`yarn start`, `yarn
start:dev`, etc).
## After PR
- Clone the project;
- Run `yarn` to install all dependencies;
- Run `yarn dev` to get started developing Unleash;
Running `yarn` should take care of everything needed to start
developing. This includes installing dependencies for frontend as well.
It should not build projects if we are not being explicit about it,
especially since we don't need to build them at this stage.
Running `yarn dev` should start the project in dev mode. This means
running both projects in `dev` mode, which for `backend` means running
`tsc-watch` and for `frontend` means running `vite`.
Here this PR attempts to provide a better DX by using
[concurrently](https://www.npmjs.com/package/concurrently) and
[wait-on](https://www.npmjs.com/package/wait-on) - This means both tasks
are ran simultaneously, stdout is labeled accordingly, and are stopped
together. It also means that `frontend` waits for `backend` to be
serving at `4242` before starting, since `frontend` starts pretty much
immediately with `vite` and `backend` takes a bit longer. Of course,
when the `backend` is hot-reloading you may still find some
`ECONNREFUSED`s on `frontend` stdout while it recompiles.
No more splitting your terminal and treating `frontend` as a separate
project.
## Discussion points
Maybe there's a better alternative to `tsc-watch`? I briefly explored
some alternatives and while they had a much faster starting speed,
hot-reload was sometimes slower. IMO we should aspire to run
`src/server-dev.ts` directly and only compile when needed.
Running `dev:backend` still serves a version of the frontend (at 4242).
**Why? Can we remove that behavior?**
I can't imagine a scenario in dev where we wouldn't want to run the
latest version of the frontend with `vite`.
~~**Note:** This PR removes all other out-of-scope scripts to focus on
this revamp. If we decide to merge it, we should evaluate what other
existing scripts we still want to include. May be a good opportunity to
clean up unused ones and only include the ones we really use. This
includes scripts that our GH actions rely on.~~
**Update:** In an effort to minimize impact surface of this PR and make
it a bit more ready for merging:
- It updates some docs in
2a4ff805e8
and
1bbc488251
to reflect our new simplified flow;
- It includes the old package scripts for now in
039bc04699;
- It updates some of our GH actions to reflect the new scripts in
7782cb9b12;
Given its current status I'll promote the PR to "ready for review".
I still think we should have a second look at our existing scripts and
GH actions to see what we really need and/or should adapt, but it should
be a team effort so we have a broader context. Maybe on a follow-up PR.
Does this require any changes to related projects (e.g. Enterprise)?
---------
Co-authored-by: Gastón Fournier <gaston@getunleash.io>
### What
Since 3ed4aeba5c, we've updated the
segment limits and added separate limits for pro and enterprise. This PR
updates the docs with the new limits.
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
## About the changes
Update documentation to the minimum version of node. This was already
updated in other parts of the documentation
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.io>
### What
We've had this marked as deprecated through our v4, this PR removes it.
### Worth noting
This updates the deprecation notices with removal notices in the
documentation as well.
### Considerations
The tags API is still located under
/api/admin/features/{featureName}/tags. It should be moved to
/api/admin/projects/{project}/features/{featureName}/tags. I vote we do
that in a separate PR, we'd probably also need to deprecate the existing
tags endpoints for v5 and remove in v6. We could use 308s to signify
that they are moved.
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
## About the changes
Make it explicit that eventHook is no longer an option in v5, the
migration should be to
https://docs.getunleash.io/reference/addons/webhook which is already
linked in the docs since v4
<!-- 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! ❤️ -->
Adds `mode` and `defaultStickiness` to the project form.
Adds a new img
## 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: Thomas Heartman <thomas@getunleash.ai>
## About the changes
Update `passord` documentation with `password`. Note this was not a typo
but just Norwegian:
https://dictionary.cambridge.org/dictionary/english-norwegian/password
```shell
grep passord * -R -l | grep -v .git | grep -v dist | grep -v v3 | xargs sed -i 's/passord/password/g'
```
The script above avoids updating v3 because of legacy reasons
Related to #1265
<!-- 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! ❤️ -->
New PR using correct prefixes
## 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. -->
Adds documentation to the docs website for the new Jira Cloud plugin.
Couple of pieces on install page are missing due to the nature of having
to have the docs before we can start the review process after which
we'll get the final details on how/where to install/from etc.
Also a couple of pending fixes that might impact screenshots/warrant new
ones made
<!-- (For internal contributors): Does it relate to an issue on public
roadmap? -->
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#2952
### 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? -->
- website/docs/reference/integrations/jira-cloud-plugin-installation.md
- website/docs/reference/integrations/jira-cloud-plugin-usage.md
## Discussion points
<!-- Anything about the PR you'd like to discuss before it gets merged?
Got any questions or doubts? -->
Very open to improvements on wording and tips on standards used in
screenshots
---------
Co-authored-by: Simon Hornby <liquidwicked64@gmail.com>
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
This PR adds an explainer document about using large/complex
constraints, inspired by the Unleash and Redis repo.
The intent is to create a comprehensive and understandable explanation
as to why we don't recommend you do this, and also to offer alternative
solutions for the same problem.
---------
Co-authored-by: Simon Hornby <liquidwicked64@gmail.com>
<!-- 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! ❤️ -->
[Previous PR (has the
comments)](https://github.com/Unleash/unleash/pull/3405)
## 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: Thomas Heartman <thomas@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! ❤️ -->
## 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. -->
Update to Python compatibility table.
* Impression events supported in v5.6.0.
([Docs](https://docs.getunleash.io/unleash-client-python/eventcallbacks.html))
* Bootstrapping from files and custom boostrapping has been supported
since v5.2.0.
([Docs](https://docs.getunleash.io/unleash-client-python/filecache.html)
&
[Docs](https://docs.getunleash.io/unleash-client-python/customcache.html))
<!-- 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? -->
<!-- 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>
This PR changes the syntax highlighting theme we use in the docs. The
reason for the change is that the previous theme we used didn't have
sufficient color contrast between its comment strings and its
background.
## Options
I decided to use the Oceanic Next color theme that is included with
docusaurus. Looking through, the only other dark theme that also passed
AA contrast checks was VS Dark. The reason I picked Oceanic over VS Dark
is simply that I like it better.
For demonstration, here's what the Oceanic theme looks like:
And here's the VS Dark theme:
## Bonus change
The PR also includes a fix to render a pricing admonition correctly.
It's not related to the PR, but I noticed it rendered incorrectly while
I was working on it.
This PR updates the docs to clarify that we don't support multi-host
strings in the databaseUrl configuration variable.
The docs used to just mention that we accept libpq strings, but as
reported in #3221, we **don't** support multi-host strings.
I did some digging and found that this is because [node-postgres -- the
library we use to connect to postgres -- itself does not support
multi-host
strings](https://github.com/brianc/node-postgres/issues/2308).
To fix this, we would need to replace the library we use or otherwise
wrap it. While this would be a better long-term solution, we don't have
the capacity to it right now. But we can update the docs to better
reflect reality.
## About the changes
- Updates the segment information on top to be clearer - No longer an
experimental feature, but we do have some limits in place;
- Also updates the documentation to better reflect this;
Co-authored-by: @thomasheartman
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
Co-authored-by: Gastón Fournier <gaston@getunleash.ai>
This change does two things:
It clarifies that the permissions listed in the guide are permissions
needed to perform all the steps in the guide, and not the permissions
needed to create a feature.
Separates the project-level and environment-level permissions needed
into separate sublists.
This change updates the "change requests permissions" section of the
change request doc to explicitly call out a few things we've seen
confusion around recently.
These are:
- project owners can't approve/apply change requests. You must create
custom roles
- viewers can create change requests. This is intentional
- skip change requests only works via the API
It also:
- elaborates a little on the circumventing change requests section to
clarify how it works.
- adds the change requests project roles to the project roles list. This
section should be kept up to date with all the relevant roles that exist
for projects.
## About the changes
Documentation about feature toggle variants per environment
## Discussion points
The version when this will be available is still to be defined.
---------
Co-authored-by: Thomas Heartman <thomas@getunleash.ai>
## What & why
This update does three things:
1. Adjusts the environment cloning feature availability notice: because
this has been released.
2. Updates the availability notice for environments (to conform with the
standard docusaurus way of doing things): for consistency
3. Add a brief explanation of environment types: because this isn't
documented anywhere
## Sources
The note about how environment types work is sourced from this old
[slack thread (internal to the
team)](https://unleash-community.slack.com/archives/G01MU2Q49QC/p1659600175175769)
This PR expands upon the docs in the original PR (and thus supersedes #3139)
It contains the docs for the recent network view feature.
Closes#2603
---------
Co-authored-by: Gastón Fournier <gaston@getunleash.io>
Co-authored-by: Gastón Fournier <gaston@getunleash.ai>
## What
Adds environment variable equivalents for remaining authentication
options.
Also reformats the list silghtly.
## Why
Because the `AUTH_TYPE` and `AUTH_ENABLE_API_TOKEN` variables hadn't
been previously mentioned and we get questions about this from time to
time.
The reformat is primarily for using `monospace font` where appropriate.
## What
This change removes the "unleash proxy" column from the SDK compat
table.
## Why
Because the proxy isn't technically an SDK. Having the column there can
be misleading to users.
In the latest case, a user pointed out that the table says the proxy
supports `isEnabled` with fallback values, but that there is no way to
use this via the API (or via client-side sdks) at the moment.
I think we should add a section to the proxy doc about its capabilities
instead.
In fact, I think we should do the same thing with the proxy that we did
with the SDKs: merge the docs.getunleash content with the github readme
and instead source it from there.
## About the changes
This makes response time with app names enabled for everyone but also
kept a way of turning it off (kill switch) in case it cause some issues
because of misconfigured app names
## What
This PR adds a note to the constraint and the segment docs about using a
large number of constraint values.
## Why
This is a fairly common question in slack, and there is no clear
documentation around this at the moment. As such, it's likely that
people do this a fair bit without telling us. We don't think this is the
right approach, so adding this bit of documentation should hopefully
make it a little clearer.
## 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:
## About the changes
This PR prepares the GA of service accounts: OpenAPI tags, documentation
and flag removal
Relates to [roadmap](https://github.com/orgs/Unleash/projects/10) item:
#2942
---------
Co-authored-by: Nuno Góis <github@nunogois.com>
## What
This change updates the "variants" section of the Anatomy of Unleash
document with more information about how variants work with multiple
environments.
At the moment, it states that variants per env are GA from 4.21, but
that might need to be changed.
## Why
With the upcoming release of variants per environment, the doc should
reflect the current state of things. However, it should also still
contain info for those not yet on v4.21
## What
This change updates the docker compose instructions to match what is
currently in the Unleash/unleash repo itself.
## Why
Because the old version was out of date.
## What
Delete static client-side SDK docs in favor of generating them at
build time.
- Add a separate list of `clientSideSdks` to `readme-fns`.
- Use sdk type to determine which generation directory it goes into
- Replace manual sidebar category with autogenerated one
## Why
This does the same for client-side SDKs as was done for server-side
SDKs in https://github.com/Unleash/unleash/pull/2858
(Supersedes #2859)
