docs: update Epinio version to 1.13.10

docs/installation/install_epinio_cli.md

@@ -67,15 +67,15 @@ The following commands were tested using cosign version 2.1.1.
 Instead of signing all release assets, Epinio signs a file containing checksums for the release assets.
 From the repository you can download the three files:
 
-- `epinio_1.13.9_checksums.txt.pem`,
-- `epinio_1.13.9_checksums.txt.sig`,
-- `epinio_1.13.9_checksums.txt`
+- `epinio_1.13.10_checksums.txt.pem`,
+- `epinio_1.13.10_checksums.txt.sig`,
+- `epinio_1.13.10_checksums.txt`
 
 
 ```
-curl -LO https://github.com/epinio/epinio/releases/download/v1.13.9/epinio_1.13.9_checksums.txt.pem
-curl -LO https://github.com/epinio/epinio/releases/download/v1.13.9/epinio_1.13.9_checksums.txt.sig
-curl -LO https://github.com/epinio/epinio/releases/download/v1.13.9/epinio_1.13.9_checksums.txt
+curl -LO https://github.com/epinio/epinio/releases/download/v1.13.10/epinio_1.13.10_checksums.txt.pem
+curl -LO https://github.com/epinio/epinio/releases/download/v1.13.10/epinio_1.13.10_checksums.txt.sig
+curl -LO https://github.com/epinio/epinio/releases/download/v1.13.10/epinio_1.13.10_checksums.txt
 ```
 
 Once you have the three files locally, you can execute the following command
@@ -84,9 +84,9 @@ Once you have the three files locally, you can execute the following command
 cosign verify-blob \
 	--certificate-identity-regexp "https://github.com/epinio/epinio" \
 	--certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
-	--cert      epinio_1.13.9_checksums.txt.pem \
-	--signature epinio_1.13.9_checksums.txt.sig \
-	epinio_1.13.9_checksums.txt
+	--cert      epinio_1.13.10_checksums.txt.pem \
+	--signature epinio_1.13.10_checksums.txt.sig \
+	epinio_1.13.10_checksums.txt
 ```
 
 A successful output looks like
@@ -103,7 +103,7 @@ Before verifying the file integrity, you should first verify the checksum file s
 Once you’ve downloaded both the checksums and your binary, you can verify integrity by running:
 
 ```
-sha256sum --ignore-missing -c epinio_1.13.9_checksums.txt
+sha256sum --ignore-missing -c epinio_1.13.10_checksums.txt
 ```
 
 :::note
@@ -121,7 +121,7 @@ Run `epinio version` to test the successful installation.
 
 ```bash
 > epinio version
-Epinio Version: v1.13.9
+Epinio Version: v1.13.10
 Go Version: go1.20
 ```
 

docs/installation/other_inst_scenarios/install_epinio_on_rancher_desktop.md

@@ -8,7 +8,7 @@ keywords: [epinio, kubernetes, rancher, rancher desktop]
 
 This How-to uses the following versions:
 
-* [epinio helm chart 1.13.9\](https://github.com/epinio/helm-charts/releases/tag/epinio-1.13.9\)
+* \\\[epinio helm chart 1.13.10\]\\\(https://github.com/epinio/helm-charts/releases/tag/epinio-1.13.10\)
 * Rancher Desktop 1.20.0
 
 ## Rancher Desktop prerequisites

docs/references/api.md

@@ -17,7 +17,7 @@ curl -u your-username-here:password-here https://epinio.your-system-domain/api/v
 
 The responses are all JSON objects, except for some cases where you get an error before the request reaches the Epinio server (e.g. because of bad cluster configuration).
 
-The endpoints are documented in the [OpenAPI Spec](https://www.openapis.org/) format. You can find the definition of the API here: https://github.com/epinio/epinio/blob/v1.13.9/docs/references/api/swagger.json
+The endpoints are documented in the [OpenAPI Spec](https://www.openapis.org/) format. You can find the definition of the API here: https://github.com/epinio/epinio/blob/v1.13.10/docs/references/api/swagger.json
 
 __Make sure__ you change to the Epinio release you have deployed.
 

versioned_docs/version-1.13.10/explanations/_category_.json

@@ -0,0 +1,5 @@
+{
+  "label": "Explanations",
+  "position": 4,
+  "collapsed": true
+}

versioned_docs/version-1.13.10/explanations/advanced.md

@@ -0,0 +1,190 @@
+---
+sidebar_label: "Advanced topics"
+title: "Advanced topics"
+description: Advanced topics in Epinio application development environments
+keywords: [epinio, kubernetes, advanced topics]
+---
+
+## Prerequisites
+
+There are some components, such as an Ingress controller and a Certificate Manager,
+required in a Kubernetes cluster before an Epinio installation.
+The Epinio helm chart doesn't deploy these components.
+
+### Ingress controller
+
+On a Kubernetes cluster, certain services need to be reachable from outside the cluster.
+For Epinio, the `API server` is one of them.
+Some applications deployed with Epinio might also need to be reachable from outside.
+
+One way to expose services externally is by creating
+[Ingress resources](https://kubernetes.io/docs/concepts/services-networking/ingress/).
+Ingress resources on their own, have no effect.
+They're merely descriptions of the needed routing.
+An Ingress controller handles the implementation of this routing.
+
+:::note
+
+Most clusters have an Ingress controller deployed by default.
+Install [Traefik](https://doc.traefik.io/traefik/providers/kubernetes-ingress/),
+or another, if an Ingress controller is absent.
+The project uses Traefik in Epinio CI to test Epinio.
+
+There is installation documentation for
+[Traefik](../installation/install_epinio.md#ingress-controller)
+
+:::
+
+Epinio creates an Ingress resource for the Epinio API server and each application deployed.
+
+### Cert-manager
+
+[Cert-manager documentation](https://cert-manager.io/docs/)
+
+Cert-manager is a Kubernetes controller that generates and renews certificates.
+You need these certificates to securely serve the endpoints over TLS
+(for example, the Epinio API server).
+
+Epinio supports options when it comes to certificate issuers
+(Let's Encrypt, your own private CA, self signed certs).
+Cert-manager simplifies the handling of certificate issuers within Epinio.
+
+You can read more about certificate issuers in the
+[certificate issuers documentation](../howtos/other/certificate_issuers.md)
+
+## Epinio installed components
+
+The official, supported, way to install Epinio is with the
+[Epinio Helm chart](https://artifacthub.io/packages/helm/epinio/epinio).
+This Helm chart installs Epinio and it's component dependencies,
+listed below, needed for Epinio to work.
+
+### Epinio API server
+
+The main component of Epinio is the API server.
+The same `epinio` binary is both the server and the CLI.
+The server starts with the `epinio server` command within a Kubernetes Pod, configured for Epinio.
+
+Epinio CLI and web UI functionality are implemented using
+the endpoints provided by the Epinio API server component.
+For example, when the user asks Epinio to "push" an application,
+the CLI contacts the "Upload", "Stage" and "Deploy" endpoints of the Epinio API to:
+
+- upload the application code
+- create a container image for the application using this code
+- run the application on the cluster.
+
+The Epinio API server runs on the cluster.
+It's reached using Kubernetes resources like
+Deployments, Services,  Ingresses and Secrets.
+
+### Reflector
+
+[Relector documentation](https://github.com/emberstack/kubernetes-reflector)
+
+Reflector is a Kubernetes addon designed to monitor changes to resources (secrets and configmaps) and reflect changes to mirror resources in the same or other namespaces.
+
+### SeaweedFS
+
+[SeaweedFS project link](https://github.com/seaweedfs/seaweedfs)
+
+SeaweedFS is a distributed S3-compatible storage used by Epinio to store application source code.
+
+When the user pushes an application using a source code directory
+(with the [`epinio push`](../references/commands/cli/epinio_push.md) command),
+the CLI packages the source code into a tarball.
+It then uploads it to the Epinio API server.
+The API server copies that to the configured S3 storage for
+use during the staging of the application.
+
+When installing Epinio, you can use external S3 compatible storage,
+or let Epinio install SeaweedFS or s3gw on the cluster.
+See [Setup external S3](../howtos/customization/setup_external_s3.md).
+
+### s3gw
+
+[The s3gw project link](https://github.com/aquarist-labs/s3gw)
+
+S3gw is a lightweight S3-compatible solution.
+You can specify it in the Epinio Helm chart as an alternative to SeaweedFS or an external S3 provider.
+
+### Container registry
+
+The result of Epinio's application staging is a container image.
+You use this image to create a Kubernetes deployment to run the application code.
+The staging job writes the image to a container registry.
+There is further information in the
+[detailed push process](detailed-push-process.md) documentation.
+
+By default, the Epinio installation deploys a container registry inside the Kubernetes cluster, making the process fast and convenient.
+
+Epinio comes with two consumers of this registry:
+
+- Staging job - pushing the images
+- Kubernetes - pulling the images when creating a deployment for the application
+
+All consumers should communicate with the registry using TLS to encrypt communication.
+Epinio controls the staging job and it ensures that it trusts the CA used to sign the registry certificate.
+Achieving the same for Kubernetes requires configuration that's impossible from within the cluster,
+therefore Epinio has no way to ensure that it trusts the CA.
+Epinio runs in a pod of the cluster and can't have permission to change cluster settings.
+Changes are only possible, from outside, by a cluster administrator.
+
+There are 3 options:
+
+1. Let the Epinio user manually configure Kubernetes to trust the CA
+1. Use a well-known trusted CA, so there's no configuration needed
+1. Don't encrypt the communication at all
+
+Currently Epinio doesn't support the first 2 options.
+If `containerregistry.enabled` is `true` during installation (default),
+Epinio makes Kubernetes pull the images un-encrypted (the last option above).
+If you need encryption, install the container registry manually
+and configure as an ["external" registry](../howtos/customization/setup_external_registry.md)
+during Epinio installation.
+
+:::note
+
+Communication between the staging job and container registry is TLS encrypted even when using the built-in container registry.
+
+:::
+
+## Other advanced topics
+
+### Git pushing
+
+The quick way of pushing an application, explained in
+[Quickstart: push an application](../tutorials/quickstart.md#push-an-application),
+uses a local directory containing a checkout of the application's sources.
+
+Internally this is a [complex](detailed-push-process.md) procedure.
+The client creates and uploads an archive (tarball or zip)
+from the sources to the Epinio server,
+copying into Epinio's internal (or external) S3 storage.
+It's then copied from that storage to a `PersistentVolumeClaim`
+to use in the job for staging.
+Staging is the compilation and creation of the docker image
+for use by the underlying Kubernetes cluster.
+
+The process is different when using the Epinio client's "git mode".
+In this mode [`epinio push`](../references/commands/cli/epinio_push.md)
+doesn't take a local directory of sources,
+but the location of a git repository and the id of the revision to use.
+The client then asks the Epinio server to pull those sources and store them to the S3 storage.
+The rest of the process is the same.
+
+The syntax is
+
+```console
+epinio push --name NAME --git GIT-REPOSITORY-URL,REVISION
+```
+
+For comparison all the relevant syntax:
+
+```console
+epinio push
+epinio push MANIFEST-PATH
+epinio push --name NAME
+epinio push --name NAME --path DIRECTORY
+epinio push --name NAME --git GIT-REPOSITORY-URL,REVISION
+```