Add workflow to run e2e tests from lxd-ui

[edlerd]

Added a step to the GitHub test workflow, executing the e2e test suite from lxd-ui with a lxd backend built from the current branch from a PR or main branch.

We might extend this on the stable-5.21 and stable-5.0 branches, as we have dedicated test suites in lxd-ui for those. For older versions, we should continue skipping the e2e tests. I'd keep this as a second step in a followup PR.

This was successful on a fork, i.e. see this run.

[tomponline]

Hi @edlerd please can you work with @simondeziel to update this to use the pre-built LXD binaries we now have (that are compiled during the Code Tests phase) and to use the re-usable workflows for performance tuning and dependency installation.

Also i'd like to avoid building the docs twice, but they are built into the tarball i believe during the Code Tests phase so may be available already now.

[edlerd]

@simondeziel @tomponline Updated the workflow to consume the build artefacts from previous steps. Please give it another review.

[edlerd]

Also using the docs artefact by depending and downloading on that build step.

[tomponline]

This shouldnt be hardcoded into the test file, as it references an external service, and thus is a real password.

We should now change this password to something else and then securely transfer it to me so we can set it up as a GH secret.

[edlerd]

This is a dedicated free account, specially created for e2e tests. It is expected to be public. I don't see a reason for this to be kept secret.

Though once we start using the local OIDC service, we can remove this.

[tomponline]

Hrm, yeah, but we shouldnt be making the credentials public

[tomponline]

please can you move this as part of the system-tests: workflow and make it a step after name: "Run system tests (${{ matrix.suite }}, ${{ matrix.backend }})" and before name: Upload coverage data

Then we can re-use the dependency install deps, and by ensuring LXD is run with the code coverage env var, we can collect coverage data from the UI tests too.

[edlerd]

This will slow down LXD test runtime. With current changes from this PR, the UI tests run in parallel to the system tests, which will not affect your total runtime. Because system tests take longer than the UI tests. I think a better option is to also record coverage in the UI step and download both coverage reports in the TICS step.

[simondeziel]

Could that be one of the loopback IPs instead?

[edlerd]

The ui is is running in a container, so we need to use this to reach out from the container that is running the ui. Loopback would be inside the container and not reach lxd which runs on the host.