Bugfix autoresolve test reference on different stage name

[imonteroperez]

Highlights

• Current code of the plugin relies on TestObject.getId() method to setup the mapping between Jira tickets and failed tests
• Main issue here is that when we use this plugin on a multibranch pipeline with some dynamic branching names on its stages then, autoresolve capabilities will not work as expected due to some fixed tests could not be resolved, apparently because the fixed tests were executed on a different branch than the original test failure
• Root cause is because the getId method setups the branch name as part of the test reference, and this is stored in the JiraIssueKeyToTestMap.json file
• Example:

{
  "junit/plugins/LdapPluginTest/ATH___ATH_5___login_no_such_user": "JIRA-12456",
  "junit/core/PluginManagerTest/ATH___ATH_0___reproduce": "JIRA-12345",
[...]
}

• So, if LdapPluginTest#login_no_such_user is fixed on next execution, BUT it is executed in a different branch, then it will not be marked as resolved
• Proposed fix is to search the issue key related to the test in the Jira server if it does not mach with the one from the local map.

Testing performed

• Created a single pipeline that will run the same test (test6o) to fail in different stages (ONE, TWO and THREE). It will generate something like:

{
  "junit/test/SomeTest/test6o": "JIRA-66",
  "junit/test/SomeTest/TWO___test6o": "JIRA-66",
  "junit/test/SomeTest/THREE___test6o": "JIRA-66",
[...]
}

• Update the pipeline to make all to work and only execute it in the first stage ONE. Also update manually the map to just have the following entry:

{
  "junit/test/SomeTest/THREE___test6o": "JIRA-66",
}

• Once executed again, it will not be able to locate the JIRA ticket to resolve due to TestObject.getId() will not match. Thus, it will search for the key based on test in the Jira server and will transition it as expected
  

Checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests - that demonstrates feature works or fixes the issue

[andreituicu]

(Nonblocking review as I unfortunately, haven't been able to follow the development of this plugin for the past years.)

I think this could potentially create two problems:

1. The mapping will be lost for people which are updating the plugin to the new version. What is in the JSON files will no longer correspond to what the new version will look up, so all issue mappings will be lost.

2. I'm not sure if the current behaviour isn't actually the desired one. If someone has a branch for let's say 1.x.x releases, 2.x.x releases and a main branch. They might still have tests which have the same name, but it is very possible that some tests are broken in the 1.x.x branch and main. They will probably not want to have the passing tests on the 2.x.x releases close the issues from the other branches, as these codebases have diverged. Or a simpler scenario, you might not want to have the issues opened from the main branch be closed by tests passing from branches which might never get merged due to code reviews.

I hope this helps! These are just some perspectives for you to consider. 🙂

[imonteroperez]

(Nonblocking review as I unfortunately, haven't been able to follow the development of this plugin for the past years.)

I think this could potentially create two problems:

1. The mapping will be lost for people which are updating the plugin to the new version. What is in the JSON files will no longer correspond to what the new version will look up, so all issue mappings will be lost.
2. I'm not sure if the current behaviour isn't actually the desired one. If someone has a branch for let's say 1.x.x releases, 2.x.x releases and a main branch. They might still have tests which have the same name, but it is very possible that some tests are broken in the 1.x.x branch and main. They will probably not want to have the passing tests on the 2.x.x releases close the issues from the other branches, as these codebases have diverged. Or a simpler scenario, you might not want to have the issues opened from the main branch be closed by tests passing from branches which might never get merged due to code reviews.

I hope this helps! These are just some perspectives for you to consider. slightly_smiling_face

Thanks for the feedback @andreituicu ! I will take it into consideration. Moving the PR to draft mode to tackle this ^.

[imonteroperez]

(Nonblocking review as I unfortunately, haven't been able to follow the development of this plugin for the past years.)
I think this could potentially create two problems:

1. The mapping will be lost for people which are updating the plugin to the new version. What is in the JSON files will no longer correspond to what the new version will look up, so all issue mappings will be lost.
2. I'm not sure if the current behaviour isn't actually the desired one. If someone has a branch for let's say 1.x.x releases, 2.x.x releases and a main branch. They might still have tests which have the same name, but it is very possible that some tests are broken in the 1.x.x branch and main. They will probably not want to have the passing tests on the 2.x.x releases close the issues from the other branches, as these codebases have diverged. Or a simpler scenario, you might not want to have the issues opened from the main branch be closed by tests passing from branches which might never get merged due to code reviews.

I hope this helps! These are just some perspectives for you to consider. slightly_smiling_face

Thanks for the feedback @andreituicu ! I will take it into consideration. Moving the PR to draft mode to tackle this ^.

@andreituicu again thanks for your feedback! I updated the PR with a different approach (non-replacing the test.getId by the test.getTransformedFullDisplayName) to ensure backward compatibility. This new approach is based on to query the Jira server to detect which issues should be transitioned if there is no match on querying the map (based on different stages names)