OCPERT-319: Rename JenkinsException to JenkinsHelperException to avoid naming conflict

[rioliu-rh]

Summary

Final cleanup for OCPERT-319 exception refactoring: Rename custom JenkinsException to JenkinsHelperException to avoid naming conflict with the jenkins library's exception class.

This PR fixes two issues discovered after #897 and #898:

1. Import name shadowing - The jenkins library's JenkinsException was inaccessible
2. Bare except: anti-pattern - Line 186 in jenkins.py used bare except to work around the shadowing issue

Root Cause

The original code had:

from jenkins import JenkinsException         # Line 5: jenkins library's exception
from oar.core.exceptions import JenkinsException  # Line 10: SHADOWS line 5

This meant:

• Jenkins API calls raise jenkins.JenkinsException (from the library)
• But we couldn't catch it because the import was shadowed
• So line 186 used bare except: to catch everything
• Exception handlers at lines 43, 53, 193, 207 couldn't properly catch jenkins API exceptions

Changes

1. Rename Exception Class

• oar/core/exceptions.py: JenkinsException → JenkinsHelperException

2. Fix oar/core/jenkins.py (7 locations)

• Import: Use JenkinsHelperException (our custom exception)
• Keep: from jenkins import JenkinsException (jenkins library - no longer shadowed)
• Raise statements (13x): Use JenkinsHelperException
• Exception handlers (4x): Catch (JenkinsException, JenkinsHelperException)
  • JenkinsException - from jenkins library API calls
  • JenkinsHelperException - from our own code
• Fix bare except: on line 186:

  # Before:
  except:
      raise JenkinsException(f"visit {queue_item_link} failed")
  
  # After:
  except (JenkinsException, Exception) as e:
      raise JenkinsHelperException(f"visit {queue_item_link} failed: {e}") from e

3. Update CLI Commands

• oar/cli/cmd_stage_testing.py: Import and usage (1 location)
• oar/cli/cmd_image_consistency_check.py: Import and usage (2 locations)

Exception Handling Pattern

The new pattern is explicit and clear:

try:
    # Code that may raise jenkins.JenkinsException (from API)
    # or JenkinsHelperException (from our code)
    self.server.build_job(...)
except (JenkinsException, JenkinsHelperException) as e:
    # Always re-raise as our custom exception
    raise JenkinsHelperException("operation failed") from e

Benefits

1. ✅ No naming conflict - Both exceptions are accessible
2. ✅ No bare except - Explicit exception handling, allows system signals to propagate
3. ✅ Clear semantics - Name reflects it's from JenkinsHelper, not jenkins library
4. ✅ Proper chaining - Uses from e to preserve exception context
5. ✅ Follows convention - Matches other exception names (AdvisoryException, JiraException, etc.)

Testing

• All files compile successfully
• Exception handling patterns verified with test cases
• Catches both jenkins API and custom helper exceptions correctly

Related: #897, #898

[openshift-ci-robot]

@rioliu-rh: This pull request references OCPERT-319 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Summary

Final cleanup for OCPERT-319 exception refactoring: Rename custom JenkinsException to JenkinsHelperException to avoid naming conflict with the jenkins library's exception class.

This PR fixes two issues discovered after #897 and #898:

1. Import name shadowing - The jenkins library's JenkinsException was inaccessible
2. Bare except: anti-pattern - Line 186 in jenkins.py used bare except to work around the shadowing issue

Root Cause

The original code had:

from jenkins import JenkinsException         # Line 5: jenkins library's exception
from oar.core.exceptions import JenkinsException  # Line 10: SHADOWS line 5

This meant:

• Jenkins API calls raise jenkins.JenkinsException (from the library)
• But we couldn't catch it because the import was shadowed
• So line 186 used bare except: to catch everything
• Exception handlers at lines 43, 53, 193, 207 couldn't properly catch jenkins API exceptions

Changes

1. Rename Exception Class

• oar/core/exceptions.py: JenkinsException → JenkinsHelperException

2. Fix oar/core/jenkins.py (7 locations)

• Import: Use JenkinsHelperException (our custom exception)
• Keep: from jenkins import JenkinsException (jenkins library - no longer shadowed)
• Raise statements (13x): Use JenkinsHelperException
• Exception handlers (4x): Catch (JenkinsException, JenkinsHelperException)
• JenkinsException - from jenkins library API calls
• JenkinsHelperException - from our own code
• Fix bare except: on line 186:

# Before:
except:
    raise JenkinsException(f"visit {queue_item_link} failed")

# After:
except (JenkinsException, Exception) as e:
    raise JenkinsHelperException(f"visit {queue_item_link} failed: {e}") from e

3. Update CLI Commands

• oar/cli/cmd_stage_testing.py: Import and usage (1 location)
• oar/cli/cmd_image_consistency_check.py: Import and usage (2 locations)

Exception Handling Pattern

The new pattern is explicit and clear:

try:
   # Code that may raise jenkins.JenkinsException (from API)
   # or JenkinsHelperException (from our code)
   self.server.build_job(...)
except (JenkinsException, JenkinsHelperException) as e:
   # Always re-raise as our custom exception
   raise JenkinsHelperException("operation failed") from e

Benefits

1. ✅ No naming conflict - Both exceptions are accessible
2. ✅ No bare except - Explicit exception handling, allows system signals to propagate
3. ✅ Clear semantics - Name reflects it's from JenkinsHelper, not jenkins library
4. ✅ Proper chaining - Uses from e to preserve exception context
5. ✅ Follows convention - Matches other exception names (AdvisoryException, JiraException, etc.)

Testing

• All files compile successfully
• Exception handling patterns verified with test cases
• Catches both jenkins API and custom helper exceptions correctly

Related: #897, #898

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci-robot]

@rioliu-rh: This pull request references OCPERT-319 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Summary

Final cleanup for OCPERT-319 exception refactoring: Rename custom JenkinsException to JenkinsHelperException to avoid naming conflict with the jenkins library's exception class.

This PR fixes two issues discovered after #897 and #898:

1. Import name shadowing - The jenkins library's JenkinsException was inaccessible
2. Bare except: anti-pattern - Line 186 in jenkins.py used bare except to work around the shadowing issue

Root Cause

The original code had:

from jenkins import JenkinsException         # Line 5: jenkins library's exception
from oar.core.exceptions import JenkinsException  # Line 10: SHADOWS line 5

This meant:

• Jenkins API calls raise jenkins.JenkinsException (from the library)
• But we couldn't catch it because the import was shadowed
• So line 186 used bare except: to catch everything
• Exception handlers at lines 43, 53, 193, 207 couldn't properly catch jenkins API exceptions

Changes

1. Rename Exception Class

• oar/core/exceptions.py: JenkinsException → JenkinsHelperException

2. Fix oar/core/jenkins.py (7 locations)

• Import: Use JenkinsHelperException (our custom exception)
• Keep: from jenkins import JenkinsException (jenkins library - no longer shadowed)
• Raise statements (13x): Use JenkinsHelperException
• Exception handlers (4x): Catch (JenkinsException, JenkinsHelperException)
• JenkinsException - from jenkins library API calls
• JenkinsHelperException - from our own code
• Fix bare except: on line 186:

# Before:
except:
    raise JenkinsException(f"visit {queue_item_link} failed")

# After:
except (JenkinsException, Exception) as e:
    raise JenkinsHelperException(f"visit {queue_item_link} failed: {e}") from e

3. Update CLI Commands

• oar/cli/cmd_stage_testing.py: Import and usage (1 location)
• oar/cli/cmd_image_consistency_check.py: Import and usage (2 locations)

Exception Handling Pattern

The new pattern is explicit and clear:

try:
   # Code that may raise jenkins.JenkinsException (from API)
   # or JenkinsHelperException (from our code)
   self.server.build_job(...)
except (JenkinsException, JenkinsHelperException) as e:
   # Always re-raise as our custom exception
   raise JenkinsHelperException("operation failed") from e

Benefits

1. ✅ No naming conflict - Both exceptions are accessible
2. ✅ No bare except - Explicit exception handling, allows system signals to propagate
3. ✅ Clear semantics - Name reflects it's from JenkinsHelper, not jenkins library
4. ✅ Proper chaining - Uses from e to preserve exception context
5. ✅ Follows convention - Matches other exception names (AdvisoryException, JiraException, etc.)

Testing

• All files compile successfully
• Exception handling patterns verified with test cases
• Catches both jenkins API and custom helper exceptions correctly

Related: #897, #898

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign jhuttana for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci]

@rioliu-rh: all tests passed!

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.