github.com/redhat-appstudio/e2e-tests@v0.0.0-20240520140907-9709f6f59323/tests/rhtap-demo/README.md (about)

     1  # RHTAP demo test
     2  
     3  ### Prerequisites for running the advanced build scenario against your own cluster
     4  1. Fork https://github.com/redhat-appstudio-qe/hacbs-test-project and https://github.com/redhat-appstudio-qe/strategy-configs to your GitHub org (specified in `MY_GITHUB_ORG` env var)
     5  2. Make sure the cluster you are about to run this test against is public (i.e. hosted on a public cloud provider)
     6  
     7  ### Description
     8  This test simulates typical user scenario.
     9  
    10  #### Note
    11  
    12  In order to run this test against **staging** cluster, export following environment variables (after updating their values with valid data) and run the test suite:
    13  ```bash
    14  export STAGEUSER_TOKEN=<Offline token used for getting Keycloak token in order to authenticate against stage> \
    15  STAGE_SSOURL=<Keycloak URL used for authentication against stage cluster> \
    16  STAGE_APIURL=<Toolchain API URL used for authentication against stage cluster> \
    17  STAGE_USERNAME=<Your stage cluster username>
    18  # Run the test suite
    19  ginkgo --label-filter='verify-stage' ./cmd/
    20  ```
    21  
    22  
    23  #### Simple build
    24  1. Setup
    25     1. Create a user namespace
    26     2. Inject manual SPI token
    27  
    28  2. Test Scenario
    29     1. The application was created successfully and is healthy
    30     2. The POC environment was created successfully
    31     3. The Component Detection Query was created successfully
    32     4. The Component (simple) Build finished successfully
    33     5. Snapshot was created and integration test finished successfully
    34  
    35  ### Advanced build (enabled only if AdvancedBuildSpec is set)
    36  1. Setup
    37     1. Create a managed namespace used by release service for validating and releasing the built image
    38     2. Create required resources in managed-namespace
    39        1. Secret with container image registry credentials (used for pushing the image to container registry)
    40        2. Service account that mounts the secret, including required roles and rolebindings
    41        3. PVC for the release pipeline
    42        4. Secret with cosign-public-key (used for validating the built image by EC)
    43        5. Release plan for the targeted application and (user) namespace
    44        6. Release strategy, Release plan admission
    45        7. Enterprise contract policy
    46     3. Create a new branch in a java project on GitHub (that is used as a git source of a component) that will be used as a base branch for PaC pull request (so we don't pollute default branch - `main`)
    47     4. Create a new application, test environment
    48     5. Create a new component that will trigger the "advanced" build pipelinerun
    49     6. Create JBSConfig and related secret in user's (dev) namespace that will trigger jvm-build-service to deploy a jvm-cache to the dev namespace, which will be used for caching java dependencies during build
    50  
    51  2. Test scenario
    52     1. Verify that the initial PaC pull request was created in the component's repo (this will also trigger an advanced build pipelinerun)
    53     2. After merging the PR, there should be another build pipelinerun triggered in user namespace
    54     3. Make sure the pipelinerun completes successfully
    55     4. Make sure that the resulting SBOM file can be pulled from the container registry (where also the image was pushed) and it is saved in expected format
    56     5. Make sure that integration test pipelinerun is created and completes successfully
    57     6. The release pipeline should succeed and the release should be marked as successful
    58     7. Make sure JVM build service is used for rebuilding java component's dependencies and that all related dependency builds complete successfully
    59  
    60  Steps to run 'rhtap-demos':
    61  
    62  1) Follow the instructions from the [Readme](../../docs/Installation.md) scripts to install AppStudio in e2e mode
    63  2) Run the e2e suite: `./bin/e2e-appstudio --ginkgo.label-filter="rhtap-demo"`
    64  
    65  ## Test Generator
    66  
    67  The test specs in rhtap-demo-suite are generated dynamically using ginkgo specs.
    68  
    69  If you want to test your own Component (repository), all you need to do is to update the `TestScenarios` variable in [scenarios.go](./config/scenarios.go)
    70  
    71  ## Run tests with private component
    72  
    73  Red Hat AppStudio E2E framework now supports creating components from private quay.io images and GitHub repositories.
    74  
    75  #### Environments
    76  
    77  | Variable | Required | Explanation | Default Value |
    78  |---|---|---|---|
    79  | `QUAY_OAUTH_USER` | yes | A quay.io username used to push/build containers  | ''  |
    80  | `QUAY_OAUTH_TOKEN` | yes | A quay.io token used to push/build containers. Note: the token and username must be a robot account with access to your repository | '' |
    81  
    82  #### Setup configuration for private repositories
    83  
    84  1. Define in your configuration for the application and the component
    85  Example of a test scenario for GitHub private repository:
    86  
    87  ```go
    88  var TestScenarios = []TestSpec{
    89      {
    90          Name:            "nodejs private component test",
    91          ApplicationName: "nodejs-private-app",
    92          Components: []ComponentSpec{
    93              {
    94                  Name:              "nodejs-private-comp",
    95                  Private:           true,
    96                  Language:          "JavaScript",
    97                  GitSourceUrl:      "https://github.com/redhat-appstudio-qe-bot/nodejs-health-check.git",
    98                  HealthEndpoint:    "/live",
    99              },
   100          },
   101      },
   102  }
   103  ```
   104  
   105  2. Run the e2e tests