Test upstream button may cause misleading UX when testing unsaved changes

Context

This issue is a follow-up to #560922 (closed), specifically addressing the limitation identified in #560922 (comment 2705576278).

During the implementation of the "Test upstream" button for Maven upstream forms, a limitation was identified with the Maven upstream test API.

Problem

The current Maven upstream test API does not allow passing additional parameters for an existing upstream. This creates a misleading user experience on the Edit upstream page:

User Journey:

  1. User opens an existing upstream for editing
  2. User modifies upstream details (URL, credentials, etc.) in the form
  3. User clicks "Test upstream" button without saving first
  4. API tests connection using stored values instead of current form values
  5. User receives test results that don't reflect their proposed changes

This disconnect between what the user sees in the form and what gets tested can lead to confusion and poor user experience.

Impact

  • Users may think their changes work when they don't (false positive)
  • Users may think their changes don't work when they do (false negative)
  • Reduces confidence in the test functionality
  • Forces users to save changes before testing, disrupting workflow

Proposed Solution

Enhance the Maven upstream test API to accept optional parameters:

  • When testing existing upstreams, allow override parameters for URL, credentials, etc.
  • Use provided parameters for testing instead of stored configuration
  • Maintain backward compatibility when no parameters are provided
  • Enable accurate testing of unsaved form changes

Implementation

Add a new POST API endpoint (same path as the current GET endpoint) that takes the upstream_id with optional override values for url, username and password.

This same endpoint can be used for testing existing upstreams and updated values.

Update the edit form test button to use this endpoint, and also the link existing upstream test button.

Update docs.

We can deprecate the existing GET endpoint as this new endpoint will handle both. Create separate issue to track deprecating the GET endpoint.

Related Issues

Edited by 🤖 GitLab Bot 🤖