Uploaded image for project: 'Hybrid Application Console'
  1. Hybrid Application Console
  2. HAC-2382

Workspace Selector logic in HAC using cookies

XMLWordPrintable

    • Icon: Story Story
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • None
    • Core
    • None
    • False
    • False
    • None

      September 23rd discussion notes:

      Question: Will HAC on console-dev.redhat.com be able to have logic where it can switch to a different CPS dynamically and connect to the correct workspace?  Otherwise we would have to deploy additional HAC instances (using ephemeral hac) for each test run. Follow up with Pete and Sam.

      For a number of reasons, from the App Studio side, we would prefer to point to a long-running instance of console dot rather than create ephemeral HAC instances for each test run.  So we discussed how we could make that work.

       

      For a long-running instance, we talked about three ways to implement this “workspace selector” logic in HAC: using cookies, using query parameters, and using a proxy.

      • A proxy would make the test environment less production-like, so we don’t like that option. 
      • Query parameters have a tendency to get accidentally lost as we’re clicking through screens. In fact it’s quite difficult to guarantee that they won’t be lost at some point in the test flow, so we don’t like that option either.
      • The preferred option is to have the test framework (i.e. Cypress, Selenium) set a cookie with the workspace information HAC will need.
      • Side note: The HAC Cypress tests will need a workspace passed in anyway. You can definitely set a cookie w/Cypress.

       

      We discussed test users and test workspaces.

      • We can create multiple service provider workspaces per user home workspace; that is supported by KCP.
      • See the existing create-user-workspace script in infra-deployments.
      • Therefore we can start with one or a few test users, and create different workspaces for each CI test run under their home workspace(s). We don’t need a pool of, say, 50 test users.

       

      We discussed which long-running instance to use.

      • We’re testing the main/master branch in both App Studio and HAC.
      • We intend to run our App Studio E2E tests with the latest code from HAC that's been merged and the commit of App Studio that we are testing. 
      • We intend to run our HAC E2E tests with the latest code from App Studio that's been merged and the commit of HAC that we are testing. 
      • We want to get to where main/master is what's in production for HAC, or something very close to it. We’re not there today. Today the latest HAC is only on console-dev. So we will have to point our tests at console-dev.redhat.com for the time being.
      • Do we want to avoid testing with production HAC? It should be OK to use production HAC for E2E tests and PR tests; as long as it's not massive scale/load testing or pen testing.

            spadgett@redhat.com Samuel Padgett
            psrna Pavol Srna
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: