docs: update GH action

[ypoplavs]

Pull request description

Checklist (choose whats happened)

• breaking change! (describe)
• tested locally
• tested on cluster
• added new dependencies
• updated the docs
• added a test

Breaking changes

Changes

Fixes

[netlify]

✅ Deploy Preview for testkube-docs-preview ready!

Name	Link
🔨 Latest commit	e87cae8
🔍 Latest deploy log	https://app.netlify.com/sites/testkube-docs-preview/deploys/6540c1a5ac5f5c000829f7c6
😎 Deploy Preview	https://deploy-preview-4496--testkube-docs-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[TheBrunoLopes]

I feel we need to make this doc a bit more easy to understand. (maybe it's just me)
Around the use cases or goals.

My suggestions are:

• First we tell our users what they can do and what is this Github Actions we did.

• These section titles seem very similar.

• We are showing an example and explaining what it does
  Instead the docs should be focused on what the users wants or can do and then showing examples.
  We have a section on Configuring GH actions with GKE, but we don't tell why or what does it mean to connect to GKE.

We should tell them what is the purpose, and what each action does.

For example:

• deploy tests, here's an example
• create tests, here;s another example
• connect to the cloud. here's how to do it.

[jfermi]

A few editing suggestions.

[jfermi]

Some editing suggestions.

[rangoo94]

Besides specific comments, we should sort out:

• Sections - for better navigation
• Secrets - explain or avoid them
  • Maybe the easiest way would be to use env: section with plain-text data, so Users may easily replace just such section with {{secrets.someName}}

[rangoo94]

Create and run tests on the open source Testkube for AWS provider.

I feel that it would imply that there is some specific version of Testkube for different providers, while it is about Cloud provider for the Kubernetes

[ypoplavs]

...Please mind that it requires additional steps to establish connection with the k8s cluster. While this step will be different for each provider, Testkube Action will stay unchanged. ?

[rangoo94]

To be honest, I don't know if it's a matter of a single sentence. Maybe we just need to reorganize the documentation, to be more straight-forward - so reading from top to bottom, gives you clear information - then you may either skip a section, or get a knowledge needed to continue, without ever getting back.

As an example, although it's rather not written well:

Configuring workflow for Testkube Open Source

To use Testkube CLI for Open Source installation, you need to configure your kubectl with the Kubernetes cluster, and simply use Testkube Action.

steps:
  # Configure Kubernetes cluster connection
  # [...] <-- Put here steps for configuring your connection

  # Configure Testkube
  - uses: kubeshop/setup-testkube@v1

If you have your Testkube installed in custom namespace, not testkube, you need to add a parameter for Testkube Action:

  - uses: kubeshop/setup-testkube@v1
     with:
       namespace: testkube

Steps to connect to your Kubernetes cluster differ for each provider. You should check the docs of your Cloud provider on how to connect to the Kubernetes cluster from GitHub Action, or check examples in this documentation for selected providers.

Connecting to cluster in AWS EKS

To connect to AWS EKS, you may use such steps:

  # Configure Kubernetes cluster connection
  - uses: aws-actions/configure-aws-credentials@v4
    with:
      aws-access-key-id: ${{ secrets.AwsAccessKeyId }}
      aws-secret-access-key: ${{ secrets.AwsSecretAccessKey }}
      aws-region: ${{ secrets.AwsRegion }}

  - run: |
      aws eks update-kubeconfig --name ${{ secrets.EksClusterName }} --region ${{ secrets.AwsRegion }}

  # Configure Testkube
  # [...]

We've used secrets here for vulnerable data, but you may put plain-text information here.

• The AwsAccessKeyId, AwsSecretAccessKeyId secrets should contain your AWS IAM keys with proper permissions to connect to EKS cluster.
• The AwsRegion secret should contain AWS region where EKS is
• Tke EksClusterName secret points to the name of EKS cluster you want to connect

[rangoo94]

Besides, I see that earlier we've been using examples that are full workflows (with on/jobs) that could be copy/pasted fully. I recall that @fivenp and @TheBrunoLopes did want to have it this way

[ypoplavs]

Besides, I see that earlier we've been using examples that are full workflows (with on/jobs) that could be copy/pasted fully. I recall that @fivenp and @TheBrunoLopes did want to have it this way

I mentioned this in the last sentence:

Please take a look at the [GH workflow](https://github.com/kubeshop/helm-charts/blob/develop/.github/workflows/helm-releaser-testkube-charts.yaml#L146) that is used in Testkube to deploy OSS solution to GKE cluster.

is that what you mean?

[rangoo94]

Besides, I see that earlier we've been using examples that are full workflows (with on/jobs) that could be copy/pasted fully. I recall that @fivenp and @TheBrunoLopes did want to have it this way

I mentioned this in the last sentence:

Please take a look at the [GH workflow](https://github.com/kubeshop/helm-charts/blob/develop/.github/workflows/helm-releaser-testkube-charts.yaml#L146) that is used in Testkube to deploy OSS solution to GKE cluster.

is that what you mean?

I mean simple workflows that could be copied, pasted and replaced the credentials to make it work. The link provided above may be hard to understand for a lot of people, as there is plenty of jobs, steps and other configuration, that are not only not intuitive, but also incorrect.

As an example, if someone will try to troubleshoot problems, may see in that file some stuff that should not be used, like:

      - uses: google-github-actions/get-gke-credentials@fb08709ba27618c31c09e014e1d8364b02e5042e
        with:
          cluster_name: ${{ env.GKE_CLUSTER_NAME_DEV }}
          location: ${{ env.GKE_ZONE_DEV }}
          credentials: ${{ secrets.GKE_SA_KEY }}

      - name: Install testkube kubectl plugin
        run: bash < <(curl -sSLf https://get.testkube.io )

      - name: Disable telemetry (action)
        id: disable_telemetry
        uses: kubeshop/testkube-docker-action@v1
        with:
          command: disable
          resource: telemetry

So will go only further into problems

[ypoplavs]

Besides, I see that earlier we've been using examples that are full workflows (with on/jobs) that could be copy/pasted fully. I recall that @fivenp and @TheBrunoLopes did want to have it this way

ok, so i need to extend all the mentioned examples?

name: Installing Testkube CLI
on:
  push:
      branches:
         - main
 jobs:
    install_testkube:
       runs-on: ubuntu-latest
       steps:
        - name: Checkout
           uses: actions/checkout@v4

       - name: Install Testkube CLI
          uses: kubeshop/setup-testkube@v1
          with:
             organization: ${{ secrets.TkOrganization }}
             environment: ${{ secrets.TkEnvironment }}
             token: ${{ secrets.TkToken }}

      - run: |
           testkube create test --name some-test-name --file path_to_file.json
           testkube run test some-test-name -f

smth like this will do?

[rangoo94]

smth like this will do?

@TheBrunoLopes, @fivenp, any thoughts?

[fivenp]

We should tell people why how and where to create the token mentioned here :)

[ypoplavs]

by token you mean?

[fivenp]

My main thoughts:

I would structure the doc a little bit differently.... We seem to mix quite a lot of cases here into one single doc imho. (e.g. deploying a TK Cloud helm chart installation....)

I think we can simply create 2 sections within the doc – both of them 100% focussed on this single journey:
How to use the GitHub Action to run a test on every PR automatically.

First section "How to run a test on TK Cloud on every PR with this GH Action"
Second section "How to run a test on your self hosted TK instance on every PR with this GH Action"

If we want to even go deeper with examples as David suggested (or as we right now have inside this doc) we might want to create more articles related to this GH Action and keep the content of them really sharp and to the point.

[ypoplavs]

ok, I stripped down the docs to minimum and removed all the points that may cause any confusion.
@fivenp

[jfermi]

A minor editing suggestion.

[ypoplavs]

@jfermi could you please take one last look at this?

[tvthatsme]

Do you all have any more examples of how to use the Testkube GH action for OSS? I am running into issues and there is not much out there that adds any light.