E2E test for maven request forwarding feature for group endpoints

Description of the test

• This is an test for the Maven request forwarding feature for group endpoints ( the Gitlab proxy url in settings.xml should be a group endpoint for the package)

• Before hooks:

  • Enables the feature flag :maven_central_request_forwarding with scope global before starting the test
  • Imports a maven project from a url using the browser UI
  • Fabricates a runner via docker

• The test uses Runtime::Fixtures for consumer (to install a package) and commits the settings.xml and gitlab_ci.yaml files into the project

• Then the install job is triggered in the runner from the gitlab_ci.yaml and the command "mvn install -U -s settings.xml" is triggered

• The above command, pulls the dependency listed in pom.xml file which is junit

• In the settings.xml, under mirrors, the central proxy is listed as the Gitlab package url of the project

• This means that, when the Maven package is not found in the Group Package Registry, the request is forwarded to Maven Central

• So, when the request forwarding is enabled, the pacakge install would succeed, because the pcakge will be downloaded from the Maven central

• The test expects that the install job should succeed

• After hooks:

  • Disables the feature flag :maven_central_request_forwarding
  • Removes runner from docker
  • Cleanup the package and project

Screen recording

Screen_Recording_2023-02-22_at_6.19.45_PM

How to set up and validate locally

Run from QA directory:

WEBDRIVER_HEADLESS=false GITLAB_ADMIN_PASSWORD="XXXX" GITLAB_QA_ACCESS_TOKEN=XXXX GITLAB_PASSWORD="XXXXX" QA_DEBUG=true bundle exec bin/qa Test::Instance::All http://gdk.test:3000 -- qa/specs/features/browser_ui/5_package/package_registry/maven/maven_group_level_spec.rb  --tag packages

Checklist

• Confirm the test has a testcase: tag linking to an existing test case in the test case project.
• Note if the test is intended to run in specific scenarios. If a scenario is new, add a link to the MR that adds the new scenario.
• Follow the end-to-end tests style guide and best practices.
• Use the appropriate RSpec metadata tag(s).
• Most resources will be cleaned up via the general cleanup task. Check that is successful, or ensure resources are cleaned up in the test:
  • New resources have api_get_path and api_delete_path implemented if possible.
  • If any resource cannot be deleted in the general delete task, make sure it is ignored.
  • If any resource cannot be deleted in the general delete task, remove it in the test (e.g., in an after block).
• Ensure that no transient bugs are hidden accidentally due to the usage of waits and reloads.
• Verify the tags to ensure it runs on the desired test environments.
• If this MR has a dependency on another MR, such as a GitLab QA MR, specify the order in which the MRs should be merged.
• (If applicable) Create a follow-up issue to document the special setup necessary to run the test: ISSUE_LINK
• If the test requires an admin's personal access token, ensure that the test passes on your local environment with and without the GITLAB_QA_ADMIN_ACCESS_TOKEN provided.