release docs 150

README.md

@@ -33,7 +33,56 @@ yarn run docusaurus docs:version 0.XX
 
 This will create a new version with the docs on your current branch. Do this before you start merging the docs for the next version. 
 
-After this, modify [`docusaurus.config.js`](docusaurus.config.js) to add the version to the dropdown. We typically keep the last 6 versions in the dropdown.
+Modify the `presets.docs.versions` section of  [`docusaurus.config.js`](docusaurus.config.js) as follows:
+
+
+1. Update `lastVersion` to the new official version
+
+2. Update `current` to the version in development
+
+3. Update the values of the `path` of the  previous official version in the  `versions` subsection to match the version number. 
+
+    Before
+    ```
+        '1.4': {
+            label: '1.4',
+            path: '/'
+            banner: 'none',
+        },
+    ```
+
+    After
+    ```
+        '1.4': {
+            label: '1.4',
+            path: '1.4'
+            banner: 'none',
+        },
+    ```
+
+4. Add a new entry in the `versions` subsection to match the new official version, with `/` as the path.
+
+    ```
+        '1.5': {
+            label: '1.5',
+            path: '/'
+            banner: 'none',
+        },
+    ```
+
+
+Modify the redirection rules on `netlify.toml` so that `/docs/$OFFICIAL_VERSION/` redirects to `/docs`
+
+```
+# Redirect the current version to /docs/
+[[redirects]]
+  from = "/docs/1.5/*"
+  to = "/docs/:splat"
+  status = 301
+```
+
+https://github.com/okteto/docs/pull/314 is a good example of how to set up the files
+
 
 ## Components
 

docusaurus.config.js

@@ -153,15 +153,20 @@ module.exports = {
           routeBasePath: '/',
           breadcrumbs: false,
           sidebarPath: require.resolve('./sidebars.js'),
-          lastVersion: '1.4',
+          lastVersion: '1.5',
           versions: {
             current: {
+              label: '1.6',
+              path: '1.6',
+            },
+            '1.5': {
               label: '1.5',
-              path: '1.5',
+              path: '/',
+              banner: 'none',
             },
             '1.4': {
               label: '1.4',
-              path: '/',
+              path: '1.4',
               banner: 'none',
             },
             '1.3': {

netlify.toml

@@ -8,6 +8,12 @@
   to = "/docs/self-hosted/:splat"
   status = 301
 
+# Redirect the current version to /docs/
+[[redirects]]
+  from = "/docs/1.5/*"
+  to = "/docs/:splat"
+  status = 301
+
 # Before version 1.4, we used to point the homepage to `/welcome/overview`.
 # These redirects make sure we don’t show a 404
 
@@ -16,11 +22,6 @@
   to = "/docs/"
   status = 301
 
-[[redirects]]
-  from = "/docs/1.4/welcome/overview/"
-  to = "/docs/"
-  status = 301
-
 [[redirects]]
   from = "/docs/1.3/welcome/overview/"
   to = "/docs/1.3"
@@ -65,11 +66,6 @@
   from = "/docs/0.11/welcome/overview/"
   to = "/docs/0.11"
   status = 301
-
-[[redirects]]
-  from = "/docs/1.4/*"
-  to = "/docs/:splat"
-  status = 301
 
 [[redirects]]
   from = "/*"

okteto.yml

@@ -1,25 +1,10 @@
 name: docs
 
-# The build section defines how to build the images of your development environment
-# More info: https://www.okteto.com/docs/reference/manifest/#build
 build:
   docs:
     context: .
 
 
-# The deploy section defines how to deploy your development environment
-# More info: https://www.okteto.com/docs/reference/manifest/#deploy
-deploy:
-  commands:
-    - name: Deploy
-      command: echo 'Replace this line with the proper 'helm' or 'kubectl' commands to deploy your development environment'
-
-# The dependencies section defines other git repositories to be deployed as part of your development environment
-# More info: https://www.okteto.com/docs/reference/manifest/#dependencies
-# dependencies:
-#   - https://github.com/okteto/sample
-# The dev section defines how to activate a development container
-# More info: https://www.okteto.com/docs/reference/manifest/#dev
 dev:
   docs:
     image: ${OKTETO_BUILD_DOCS_IMAGE}

versioned_docs/version-1.5/administration/cleanup.mdx

@@ -0,0 +1,69 @@
+---
+title: Resource Cleanup
+description: Okteto saves resources by putting to sleep idle applications and cleaning up unused namespaces.
+sidebar_label: Resource Cleanup
+id: cleanup
+---
+
+import Image from '@theme/Image';
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+import TiersList from '@theme/TiersList';
+
+## Sleeping resources
+
+To automatically save resources in your cluster, you can configure Okteto to automatically scale inactive applications and resources to zero if they haven't been used for longer than the `inactivity` period.
+
+## Inactive Applications and Resources
+
+Okteto considers an application or resources inactive if a user hasn't performed any of the following tasks during the `inactivity` period:
+
+- Upgrade or redeploy via the UI or the command line.
+- Launched a development container with `okteto up`.
+- Pushed the latest version of your code with `okteto push`.
+
+Service accounts, config maps, secrets, or volumes you create will be unaffected by this operation.
+
+## Wake sleeping resources
+
+Okteto's UI will notify you when there are sleeping resources in your namespace. Press the **Wake all** button to activate all sleeping resources at once.
+
+<p align="center"><Image src="/docs/administration/images/wake.png" alt="wake a sleeping resource" width="1000" /></p>
+
+Sleeping resources are also started if anyone visits any of the public endpoints of your application.
+
+## Delete Unused Namespaces
+
+Namespaces and all the resources and data contained within will be deleted if they are not used for longer than the `deletion` period.
+
+## Persistent resources  <TiersList tiers="Scale Enterprise Self-Hosted" />
+
+In case you are interested on the garbage collector but you want to skip some specific namespace, you can mark it as `persistent`. To do so, you can add the label `dev.okteto.com/persistent` to it or [use the admin view](administration/dashboard.mdx#namespaces-section).
+
+In case you want more granularity and only want to persist specific deployments or statefulsets within a namespace, you can include the label `dev.okteto.com/persistent` on those resources. In that case, the garbage collector will ignore only those specific resources while scaling down the rest of the namespace.
+
+
+## Configuration Steps  <TiersList tiers="Scale Enterprise Self-Hosted" />
+
+You can consult the `deletion` and `inactivity` periods in the [Admin Dashboard](administration/dashboard.mdx).
+
+<Tabs
+  defaultValue="self-hosted"
+  values={[
+    { label: 'Self-Hosted', value: 'self-hosted', },
+    { label: 'SaaS', value: 'saas', },
+  ]}
+>
+<TabItem value="self-hosted">
+
+You can enable and customize the `inactivity` and `deletion` periods via the [garbage collector's settings](self-hosted/administration/configuration.mdx#gc).
+
+</TabItem>
+
+<TabItem value="saas">
+
+If your instance is hosted by Okteto, [reach out to support](https://okteto.com/support) to modify this configuration.
+
+</TabItem>
+</Tabs>
+

versioned_docs/version-1.5/administration/dashboard.mdx

@@ -0,0 +1,97 @@
+---
+title: Admin Dashboard
+description: Admin Dashboard
+id: dashboard
+---
+
+import TiersList from '@theme/TiersList';
+
+# Admin Dashboard  <TiersList tiers="Scale Enterprise Self-Hosted" />
+
+The Admin Dashboard provides a web UI for administering some features of Okteto.
+
+You can access the Admin Dashboard by clicking on the `Admin` icon on the left sidebar.
+
+## Accessing the dashboard
+
+Only accounts with the administrator role will be able to access the Administration Dashboard. The first user signing up into your Okteto instance will automatically become the initial administrator.
+
+You can promote other accounts to the administrator role in the `Users` section of the Admin Dashboard or by adding the `dev.okteto.com/super: "true"` label to the corresponding `serviceAccount` in Kubernetes.
+
+## Overview Section
+
+The overview section of the Admin Dashboard shows you the following information:
+
+- Expiration date of your license
+- Number of available seats
+- Number of nodes in your cluster
+- Number of namespaces managed by Okteto
+- Number of preview environments currently active
+- Autoscaler configuration
+- Garbage Collector configuration
+
+## Users Section
+
+You can administer all users in your Okteto instance from the Admin Dashboard's Users section.
+
+For each user, an administrator will be able to:
+
+- View their name, email, and avatar
+- Change their role
+- Remove the user
+
+> Removing the user will automatically remove all the namespaces owned by the deleted user.
+
+## Nodes Section
+
+The Nodes section of the Admin Dashboard provides the following system information about your Kubernetes cluster:
+
+- Number of running pods
+- Total amount of memory currently in use
+- Total amount of memory requested
+- Total amount of CPU currently in use
+- Total amount of CPU requested
+
+You can use this information to configure [the autoscaler](self-hosted/administration/configuration.mdx#autoscaler).
+
+## Namespaces Section
+
+You can administer all namespaces in your Okteto instance from the Admin Dashboard's Namespaces section.
+
+For each namespace, an administrator will be able to:
+
+- View the name, owner, resources currently consumed, resources presently requested, and the last time it was accessed
+- Mark the namespace as `persistent` to prevent it from being automatically scaled to zero or deleted by the [garbage collector](administration/cleanup.mdx#delete-unused-namespaces)
+- Get `read-only` access to any namespace managed by Okteto
+
+## Secrets Section
+
+The Secrets section of the Admin dashboard lets you define cluster-wide secrets. Using the `$SECRET_NAME` syntax, you can refer to these secrets directly in your Okteto manifest. They are also injected into the [environment running](cloud/okteto-cli.mdx#built-in-tools-when-deploying-to-okteto-cloud) the commands in the `deploy` section of the manifest.
+
+> Secrets [defined by the user](cloud/secrets.mdx) take precedence over the secrets defined here in case of a name collision.
+
+We recommend using [build secrets](reference/manifest.mdx#build-object-optional) to inject sensitive data into your Dockerfile.
+
+The example below shows how to configure your okteto manifest to  mount a local `.env` file into your Dockerfile:
+
+```yaml
+build:
+  api:
+    context: .
+    secrets:
+      my_env: .env
+```
+
+You can refer to this secret from your Dockerfile using the syntax below:
+
+```
+RUN --mount=type=secret,id=my_env,dst=/etc/secrets/.env cat /etc/secrets/.env
+```
+
+The content of the `.env` file would be:
+
+```
+${MY_PASSWORD}
+```
+
+where `MY_PASSWORD` can be a local environment variable or an Okteto Secret, and it gets subsituted by Okteto before mounting the file as a build secret.

versioned_docs/version-1.5/administration/gitcatalog.mdx

@@ -0,0 +1,69 @@
+---
+title: Git Catalog
+description: Administrators can create a catalog of pre-defined development environments for developers to use.
+sidebar_label: Git Catalog
+id: git-catalog
+---
+
+import Image from '@theme/Image';
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+import TiersList from '@theme/TiersList';
+
+# Git Catalog  <TiersList tiers="Scale Enterprise Self-Hosted" />
+
+The Git Catalog feature enables `admins` to pre-configure a list of repositories, from the Okteto web UI, that are made available to `developers` in the same Okteto instance when they launch a dev environment from the UI. By pre-configuring these catalog entries, a developer can shorten the time it takes to deploy a development environment. With Git Catalog, developers don’t need to worry about using the right Okteto manifest or configuring the necessary environment variables.
+
+This feature gives more control to Okteto administrators over the developer experience and provides a more seamless workflow to help developers get started with their work.
+
+## Create your git catalog
+
+:::info
+
+*Only accounts with the administrator role can use this feature.*
+
+:::
+
+Within the Okteto UI, navigate to the `Admin` page and select the `Catalog` tab. On this tab, click the `Add Repository` button to open the `Add Repository` form.
+
+### Add a repository to the catalog
+
+Completing this form adds an entry to your Git Catalog, which is basically a pre-defined repository configuration that enables a developer to one-click deploy a development environment using that repository and the definition you’ve provided for it.
+
+Fill out as much of the form that makes sense for you. You will see:
+
+- Name*
+- Repository URL*
+- [Default Branch](#define-a-default-branch)
+- [Manifest Path](#define-a-manifest-path)
+- [Environment Variables](#add-environment-variables)
+
+Only the `Name` and `Repository URL` fields are required. When done, click `Save`.
+
+<p align="center"><Image src="/docs/administration/images/gc_add_repo.png" alt="add a git catalog repository" width="1000" /></p>
+
+### Define a Default Branch
+
+The default branch you specify here will be the default branch used when a developer selects this Git Catalog item to deploy a development environment.
+
+You can specify multiple catalog entries for the same `Repository URL` and set a different `Default Branch` for each one if your use case necessitates that.
+
+### Define a Manifest Path
+
+This field should (optionally) point to where your Okteto manifest resides. This provides additional control to provide a smoother experience for developers who deploy a development environment from the Git Catalog.
+
+### Add Environment Variables
+
+You can also (optionally) add Environment Variables to your Git Catalog entry to standardize how the development environment is deployed. Similar to the Default Branch entry, you could specify multiple catalog entries for the same Repository URL each with different Environment Variables.
+
+<p align="center"><Image src="/docs/administration/images/gc_add_env_vars.png" alt="add environment variables to git catalog repo" width="1000" /></p>
+
+## Launch a Dev Environment from your Git Catalog
+
+Once you’ve defined your Git Catalog entries, you can navigate to `Namespaces` → `Launch Dev Environment` → `Catalog`.
+
+In this tab you should see all of the repositories you’ve added (and pre-configured). Select an entry you wish to use and click `Launch`.
+
+<p align="center"><Image src="/docs/administration/images/gc_launch_dev_env.png" alt="launch a git catalog development environment" width="1000" /></p>
+
+<p align="center"><Image src="/docs/administration/images/gc_view_env_vars.png" alt="view a git catalog repo's environment variables" width="1000" /></p>