Skip to content

Add a Secret Push Protection test

Will Meek requested to merge secret_push_spec into master

Description of the test


As per

Test for Secret Push Protection

How to set up and validate locally

This test targets environments - Staging, Production and the Canaries. (see )

From the qa directory target Staging:

bundle install
GITLAB_QA_USER_AGENT=<USER_AGENT> GITLAB_USERNAME=<USERNAME> GITLAB_QA_ACCESS_TOKEN="<ACCESS_TOKEN>" GITLAB_PASSWORD="<GITLAB_PASSWORD>" QA_DEBUG=true WEBDRIVER_HEADLESS=false bundle exec bin/qa Test::Instance::All qa/specs/features/ee/browser_ui/13_secure/secret_push_protection_spec.rb


  • 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.

Merge request reports