Documentation for cds add github-actions (#2033)

Added some documentation for `cds add github-actions` + how to set up a
sandbox subaccount the way we did for github.com/capire.

---------

Co-authored-by: Christian Georgi <chgeo@users.noreply.github.com>

Author: swaldmann

guides/deployment/assets/github-deployment.png

@@ -16,6 +16,116 @@ status: released
 [[toc]]
 
 
+
+
+## GitHub Actions
+
+GitHub offers continuous integration using [GitHub Actions](https://docs.github.com/en/actions/automating-builds-and-tests/about-continuous-integration). In our [samples](https://github.com/capire/samples), we use simple workflows to [test, deploy and release new versions](https://github.com/capire/samples/tree/main/.github/workflows).
+
+Add a default set of workflows to your project like so:
+
+```sh
+cds add github-actions
+```
+> You can also use `cds add gha` as a shortcut.
+
+### Deploy to Staging
+
+The created workflows do a _Staging_ deployment for pushes on the `main` branch, for example after merging pull requests.
+
+If no defaults are maintained in your GitHub org, a set of variables and secrets has to be provided. Open the repository and navigate here to maintain them:
+
+`Settings` → `Secrets and variables` → `Actions`
+
+For a minimal deployment setup, these variables and secrets are required:
+
+#### Cloud Foundry
+
+| **Type**   | **Name**       | **Note**  | **Example**       |
+|------------|----------------|-----------|-------------------|
+| Variable   | `CF_API`       | API URL   | `https://api.cf.example.com` |
+|    | `CF_USERNAME`  | Username  | `user@example.com` |
+|    | `CF_ORG`       | Org Name  | `my-org`          |
+|    | `CF_SPACE`     | Space Name| `my-space`        |
+| Secret     | `CF_PASSWORD`  | Password  | `********`        |
+
+#### Kyma
+
+| **Type**   | **Name**       | **Note**  | **Example**       |
+|------------|----------------|-----------|-------------------|
+| Secret   | `KUBE_CONFIG`       | Base64-encoded Kubernetes config   | see below |
+
+
+::: details Example of a decoded `KUBE_CONFIG`
+
+Your `KUBE_CONFIG` will have to look similar to this. Make sure to replace `token` by an authorization token created for your technical user used for deployment.
+
+```yaml{6-7,11}
+apiVersion: v1
+kind: Config
+clusters:
+  - name: default-cluster
+    cluster:
+      certificate-authority-data: ...
+      server: https://api.<server ID>.stage.kyma.ondemand.com
+users:
+  - name: ci-user
+    user:
+      token: ...
+contexts:
+  - name: ci-context
+    context:
+      cluster: default-cluster
+      namespace: ci
+      user: ci-user
+current-context: ci-context
+```
+[Learn more about configuring Kubernetes](./to-kyma#configure-kubernetes){.learn-more style="margin-top:20px"}
+
+:::
+
+#### BTP Prerequisites
+
+Also make sure sufficient service entitlements are assigned to your subaccount depending on your expected usage.
+
+::: tip Set up a sandbox subaccount as an org-wide default
+
+Organization variables and secrets allow you to provide defaults for new projects without prior setup.
+
+Once required for your use case, you can easily **overwrite org-wide** variables and secrets by **repository-local** ones.
+:::
+
+#### You're set!
+
+You can now simply push any CAP project that was set up using `cds add github-actions` to your org. When merging PRs or pushing to your `main` branch, the deployment workflow will start and after some time a new entry will show up in the _Deployments_ section on your repository front page:
+
+![](./assets/github-deployment.png){style="max-width: 200px"} <!-- = image-width/2 -->
+
+### Create a GitHub Release
+
+#### Prerequisites
+
+For the actual release we want to override org-wide sandbox variables to deploy to a different subaccount/organization and database.
+
+Go to `Settings` → `Environments` → `New environment` → enter "Production".
+
+Now override org-wide variables (e.g. `CF_ORG` and `CF_SPACE` in Cloud Foundry) to use a dedicated subaccount you created for the release deployment.
+
+#### Publish the release
+
+On your repository front page go to `Releases` → `Draft a new release` → `Select tag`.
+
+Now enter a tag name, e.g. `v1.0.0` and select `Create new tag: v1.0.0 on publish`.
+
+You can optionally add a release title and release notes. Hit **Publish release** once you're ready.
+
+The release will show up in your _Releases_ page and a deployment to your production environment is started. Once finished, a _Production_ entry shows up next to _Staging_:
+
+![](./assets/github-release.png){style="max-width: 268px"} <!-- = image-width/2 -->
+
+
+
+
 <span id="afterstart" />
 
 <span id="beforecicd" />
@@ -35,8 +145,3 @@ For more flexibility you can set up continuous delivery in your software develop
 Try the tutorial [Create Automated System Tests for SAP Cloud Application Programming Model Projects](https://developers.sap.com/tutorials/cicd-wdi5-cap.html) to create system tests against a CAP-based sample application and automate your tests through a CI/CD pipeline.
 
 [See a comparison with SAP Continuous Integration and Delivery Service.](https://www.project-piper.io/){.learn-more}
-
-## GitHub Actions
-
-GitHub offers continuous integration workflows using [GitHub Actions](https://docs.github.com/en/actions/automating-builds-and-tests/about-continuous-integration). In our [SFlight sample,](https://github.com/SAP-samples/cap-sflight) we use GitHub Actions in two simple workflows to test our samples on [current Node.js and Java versions](https://github.com/SAP-samples/cap-sflight/tree/main/.github/workflows).
-