Skip to content

Latest commit

 

History

History
157 lines (112 loc) · 9.35 KB

Installation.md

File metadata and controls

157 lines (112 loc) · 9.35 KB
Raw

RHTAP Installation locally and Openshift CI

The following guide will walk through the necessary instruction about driving an installation of RHTAP locally or in Openshift CI.

RHTAP in dev mode

Requirements

Requirements for installing RHTAP in E2E mode:

  • An OpenShift 4.12 or higher Environment (If you are using CRC/OpenShift Local please also review optional-codeready-containers-post-bootstrap-configuration)
  • A machine from which to run the install (usually your laptop) with required tools:
    • A properly setup Go workspace using Go 1.19 is required
    • The OpenShift Command Line Tool (oc) Use the version corresponding to the Openshift version
    • yq
    • jq
    • git
  • Tokens
    • Github Token with the following permissions
      • repo
      • delete_repo
      • workflow
    • Valid quay token where to push RHTAP components images generated by the e2e framework

Installation

  1. Before deploying RHTAP in E2E mode you need to login to your OpenShift cluster with OpenShift Command Line Tool as admin (by default kubeadmin):

     oc login -u <user> -p <password> --server=<oc_api_url>

  2. Export required (and recommended) environment variables from default.env. Copy the file (cp default.env user.env), edit the required variables and source it (source user.env).

  3. Install dependencies:

# Install dependencies
$ go mod tidy
# or go mod tidy -compat=1.21
  1. By default the installation script will use the redhat-appstudio-qe GitHub organization for pushing changes to infra-deployments repository.

It is recommended to use your fork of infra-deployments repo in your GitHub org instead - you can change the GitHub organization with environment variable export MY_GITHUB_ORG=<name-of-your-github-org>.

Advanced installation guidelines
GitHub Application for Pipelines as Code

Some tests could require you have a Github App created in order to test Component builds via Pipelines as Code. Such tests are konflux-demo, build, and status-reporting-to-pullrequest.

In this case, before you bootstrap a cluster, make sure you created a Github App for your GitHub account. Fill in following details:

  • GitHub App name: unique app name
  • Webhook: mark as active and put some dummy URL to the Webhook URL field
  • Where can this GitHub App be installed>: Any account

Hit create, make a note of the App ID and navigate to the Private keys section where you generate a private key that gets downloaded automatically. Then export following environment variables (or if you're using .env file, update values of following variables):

export E2E_PAC_GITHUB_APP_ID='<YOUR_APP_ID>'

export E2E_PAC_GITHUB_APP_PRIVATE_KEY=$(base64 < /PATH/TO/YOUR/DOWNLOADED/PRIVATE_KEY.pem)

Navigate back to your GitHub App, select Install App and select your GitHub org (the one that you're using in `MY_GITHUB_ORG` env var). Feel free to install it to all repositories of that organization or the forked repositories currently used by konflux-demo and build tests

For bootstrapping a cluster, run the following command:

   make local/cluster/prepare

More information about how to deploy KONFLUX are in the infra-deployments repository.

Building and running the e2e tests

Most of the tests could require you to have specific container image repo's created (if you're using your own container image org/user account (QUAY_E2E_ORGANIZATION) or your own GitHub organization (MY_GITHUB_ORG). In that case, before you run the test, make sure you have created

Note: All Environments used in all e2e-tests are in default.env file. In case you need to run a specific tests, not all environments are necessary to be defined.

You can use the following make target to build and run the tests:

   make local/test/e2e

Or build and run the tests without scripts:

  1. Install dependencies and build the tests:

    # Install dependencies
$ go mod tidy
# Create `e2e-appstudio` binary in bin folder. Please add the binary to the path or just execute `./bin/e2e-appstudio`
$ make build

  2. Run the e2e tests: The e2e-appstudio command is the root command that executes all test functionality. To obtain all available flags for the binary please use --help flags. All ginkgo flags and go tests are available in e2e-appstudio binary.

       `./bin/e2e-appstudio`

Note: The binary must be updated by running make build every time there are new changes in the tests.

The instructions for every test suite can be found in the tests folder, e.g. has Readme.md. You can also specify which tests you want to run using labels or Ginkgo Focus.

KONFLUX in Openshift CI and branch pairing

The e2e tests are executed against almost all AppStudio repositories.

Sometimes when we have changes in AppStudio we are introducing some breaking changes and the e2e will fail. To prevent this the e2e framework installation in openshift-ci support a new feature of pairing the PR opened against an AppStudio repository with a corresponding PR opened against e2e-tests (based on branch names). Before the e2e framework will be executed in openshift-ci, the logic automatically tries to pair a PR opened in some repo with a branch of the same name that potentially could exists in the developer's fork of the e2e repository

For example, if a developer with GH account cooljohn opens a PR (for application-service repo) from a branch new-feature, then the logic checks if there is a PR open in e2e-tests from the new-feature branch in the cooljohn/e2e-tests fork. If such a PR is found, the CI will install the e2e framework from that branch.

Once the service PR passes CI with its pairing and is merged, the next step is to get the references in infra-deployments updated. Many services have automation to create PRs in infra-deployments to update their component to the latest version. However, this recently merged latest version will likely need the still unmerged e2e-tests update. The solution is to manually create a PR to infra-deployments that bumps the component version with the same branch name. This will allow the infra-deployments CI to run with your branch of e2e-tests, allowing the CI to pass. Finally, once the infra-deployments CI passes and PR merges, you should be able to rerun your e2e-tests PR and have it pass and merge.

To continue on the previous example, once the application-service PR merges, cooljohn should open a pull request to infra-deployments using the branch new-feature to bump the application-service version to the one recently created by the application-service PR merging. This lets the infra-deployments CI run with the required e2e-tests changes from cooljohn's fork.

Pairing PRs is handled automatically by running this command from a root directory of this repository:

   make ci/test/e2e