Open KarimJesusGalvez opened 1 year ago
Code Climate has analyzed commit b8045dbc and detected 0 issues on this pull request.
View more on Code Climate.
Hi @KarimJesusGalvez, thanks for your proposal and sorry for the delay in the response. Current implementation of Jira integration is legacy and it is being used by several projects, so it can not be modified. It is possible to add a new Jira integration, but it should not be dependant on an specific Jira schema (for instance, the issue type 'Test Case Execution' or 'Pass'/'Fail' transitions may not exist in all Jira deployments) and the implementation should be generic, allowing each project to use Jira as they need.
Hi @rgonalo, and thanks for the feedback. Funnily enough, because it's been a while, I've since moved on to other Jira projects with different issue templates, just as you say. In my case we are currently using a lot of custom fields for each issue, and I can see no good way of dealing with those (except maybe an input printing the description of the field...)
Pending tasks for now:
In my case we are currently using a lot of custom fields for each issue, and I can see no good way of dealing with those (except maybe an input printing the description of the field...)
Quick note: We should be able to pass any number of fields directly in the config file. Drawbacks:
Pending tasks for now:
- Restore the original jira upload,
- Add the JIRA dependency as optional
- command line argument to opt in the new upload method OR maybe introspect installed modules and if installed, use the new one ?
Regarding point 3, I guess that it should be better to provide a new configuration section, for example:
[IssueTracker]
enabled: true
tracker: jira
In my case we are currently using a lot of custom fields for each issue, and I can see no good way of dealing with those (except maybe an input printing the description of the field...)
Quick note: We should be able to pass any number of fields directly in the config file. Drawbacks:
- You'll be required to check your own internal names/ids of the fields in the target issue beforehand
- You would not be able to create two issue types at the same time ? (as in test execution and bug if failed for example)
One approach should be including in toolium a common implementation, creating a test execution with the corresponding status and, to enrich the information, we could provide configuration settings with data to include in additional fields. For example, something like the following section:
[IssueTracker]
enabled: true
tracker: jira
test_issue_type_name: Scenario
test_execution_issue_type_name: Scenario Execution
test_execution_status_passed: Passed
test_execution_status_failed: Failed
version_field: FixVersion
version_value: 3.0.1
Hi
I've started using tollium recently, my objective is to integrate playwright as a webdriver option, but as that is a massive undertaking to begin with, I thought I'd try to update a small part of the repo to get a better undestanding of your process.
Objective of this PR
Change the requests module in toolium/jira for the jira pipy dependency
Additions
Pending work