Use Docker to run Helm Package Registry E2E tests

🌱 Context

The current E2E test for Helm Package Registry does the package publishing and package download inside a pipeline. To trigger a pipeline, it creates a commit. It includes steps that are not really related to Helm Package Registry, among them:

• running a pipeline
• creating a commit to trigger a pipeline

The Helm E2E tests check the three authentication we support:

• personal access token
• deploy token
• CI/CD token

Naturally, we'll still need to run the CI/CD token E2E test in a pipeline. But the personal access token and deploy token tests can be run outside a pipeline, in a docker container.

What does this MR do and why?

Run the Helm Package Registry E2E tests, for personal access tokens and deploy tokens, in a Docker container.

This approach mirrors the approach followed by a similar spec for the Maven Package Registry. This approach was also followed in a recent MR for the Maven Gradle E2E specs.

The base container image used was alpine/helm (130MB). alpine/helm is a bigger image than alpine (13MB) which is used in the CI pipeline. But it already includes the helm binary, so we can skip the step to download this binary, which happens for every spec run. I also tried using this image in the CI pipeline, in a separate MR, but for reasons I do not understand, the pipeline failed.

References

• Investigate & Fix/Quarantine test file: /browse... (#550595 - closed)
  • Discussion on running on CI pipeline vs. running outside CI pipeline
• !Run E2E Gradle tests on Docker (!201131 - merged)

Screenshots or screen recordings

NA

How to set up and validate locally

Run the E2E tests locally against GDK, e.g. WEBDRIVER_HEADLESS=false GITLAB_QA_ADMIN_ACCESS_TOKEN='<root-pat>' GITLAB_USERNAME='root' QA_LOG_LEVEL=DEBUG QA_GITLAB_URL=http://gdk.test:3000 bundle exec rspec qa/specs/features/browser_ui/5_package/package_registry/helm_registry_spec.rb

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #550595 (closed)