feat: Release candidate v0.44.0

[arunjaindev]

Description

Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.

Fixes https://github.com/devtron-labs/sprint-tasks/issues/2743

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• Test A
• Test B

Checklist:

• The title of the PR states what changed and the related issues number (used for the release note).
• Does this PR require documentation updates?
• I've updated documentation as required by this PR.
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas

[github-actions]

Some linked issues are invalid. Please update the issue links:\nIssue # in is not found or invalid (HTTP }404).\n

[sonarqubecloud]

Quality Gate passed

Issues
6 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

General fix:
To resolve the ambiguity and prevent catastrophic backtracking, the ambiguous sub-patterns must be rewritten. This is typically done by ensuring that within a repeated group, no part can match the same string in multiple ways. In this case, [\w.-]+ should be rewritten to make . and - unambiguous, typically by not allowing them to be adjacent to each other in a way that would create ambiguity, or by splitting host/domain validation into stricter components.

Best detailed fix:
Rewrite the pattern to avoid [.-] inside a repetition over the group. In the context of validating a URL, it's better to switch to a stricter hostname/domain matching pattern. For common domain validation, one can use:

• Each label: [a-zA-Z0-9-]+ (cannot start/end with -)
• Separated by ., at least one .
  But for quick practical repairs (avoiding extensive rewriting), replace [\w.-]+ with [\w-]+(?:\.[\w-]+)* which means "one or more word/dash, optionally repeated, separated by "."". This approach avoids the ambiguity.
  The overall regex could become:

/^(http(s)?:\/\/)[\w-]+(?:\.[\w-]+)+[\w\-._~:/?#[\]@!$&'()*+,;=.]+$/

Alternatively, if strict URL validation is needed, consider using a trusted library (e.g. validator.js) instead of custom regex, but as per the prompt, only touch what we've been shown.

Where to change:
In file src/Pages/GlobalConfigurations/ClustersAndEnvironments/ClusterForm/utils.tsx, at line 62, change the regular expression to use [\w-]+(?:\.[\w-]+)+.

What's needed:

• Only code edit — no new imports or methods necessary.

To fix this problem, we need to remove ambiguity from the repeated subexpression by ensuring that each repetition can't match the same string via different paths. Specifically, [\w.-]+ can be ambiguous since . and - can be matched by more than one iteration. Instead, for validating domain names, a safer approach is to split alternation so that periods are treated as separators, not as possible characters within the repeated part, or to use a more specific character class such as [\w-] (excluding period) for matching domain labels, and use (?:\.[\w-]+)+ for subsequent parts.

The best way to fix this, focusing only on the snippet shown, is to change [\w.-]+(?:\.[\w.-]+)+ to [\w-]+(?:\.[\w-]+)+. This ensures:

• Each domain label is [\w-]+
• Labels are separated by a literal dot
• No ambiguity between dot and other characters inside the repeated group.

Apply this change on line 94 and also on line 62, since both use the same pattern. No external dependencies or additional imports are required as this is a pure regex fix.

---