github.com/redhat-appstudio/e2e-tests@v0.0.0-20230619105049-9a422b2094d7/tests/mvp-demo/README.md (about)

     1  # MVP demo test
     2  
     3  ### Prerequisites for running this test 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  
     9  This test simulates the "simple build -> deploy -> (failed) release" to "advanced -> build -> scan -> test -> release" user journey
    10  
    11  For simulating the failed release we are using a custom docker-build template that contains a container image coming from ["untrusted" container image registry](https://github.com/enterprise-contract/ec-policies/blob/2d9fc8317a6349a4a9a1969f16c90dfec4448cd3/data/rule_data.yml#L9-L18). This should guarantee that the EC validation will fail and cause the failure of the release process.
    12  
    13  ### Test steps
    14  1. Setup
    15     1. Create a user and a related (dev) namespace, create a managed namespace used by release service for validating and releasing the built image
    16     2. Create required resources in managed-namespace
    17        1. Secret with container image registry credentials (used for pushing the image to container registry)
    18        2. Service account that mounts the secret, including required roles and rolebindings
    19        3. PVC for the release pipeline
    20        4. Secret with cosign-public-key (used for validating the built image by EC)
    21        5. Release plan for the targeted application and (user) namespace
    22        6. Release strategy, Release plan admission
    23        7. Enterprise contract policy
    24  1. Chapter 1 (simple app build, deploy, (failed) release)
    25     1. Setup
    26        1. 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`)
    27        2. Create a new application, test environment
    28        3. Create a build pipeline selector with pipeline ref pointing to a custom build-template, that contains an image which should fail the EC validation (for more information see the [Description](#description))
    29        4. Create a new component that will trigger the "simple" build pipipelinerun
    30     2. After the component is built, check that the component is deployed (by checking the related deployment status) and check that the component route can be accessed
    31     3. Check that Snapshot and Release CRs are created and Release PipelineRun has started
    32     4. Eventually the release of the container image (that was built by the custom-untrusted pipelinerun) should fail for the reasons mentioned above
    33  2. Chapter 2 (advanced build, JVM rebuild, successful release)
    34     1. Setup
    35        1. 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
    36     2. Update the existing component to contain the annotation `skip-initial-checks: false` which indicates that this time we will use "advanced build" (that includes tasks for performing security checks)
    37     3. Verify that the initial PaC pull request was created in the component's repo (this will also trigger an advanced build pipelinerun)
    38     4. After merging the PR, there should be another build pipelinerun triggered in user namespace
    39     5. Make sure the pipelinerun completes successfully
    40     6. 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
    41     7. This time we used official build-templates (that use container images from trusted registry), so the release pipeline should succeed and the release should be marked as successful
    42     8. Make sure JVM build service is used for rebuilding java component's dependencies and that all related dependency builds complete successfully