Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Telefonica jira update #358

Open
wants to merge 34 commits into
base: master
Choose a base branch
from

Conversation

KarimJesusGalvez
Copy link

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

  • A Jira documentation file with a configuration example
  • Ability to select the target project for the upload
  • Creates a new execution of the test per upload, instead of updating the Test issue directly
  • Added more log statements

Pending work

  • Needs more unit tests and an extra pass on the original tests
  • Attachements are uploaded in bulk, regardless of the test that created them
  • Likewise the log file is uploaded as it is, previous executions if any included

toolium/jira.py Outdated Show resolved Hide resolved
toolium/jira.py Outdated Show resolved Hide resolved
toolium/jira.py Show resolved Hide resolved
toolium/jira.py Outdated Show resolved Hide resolved
@codeclimate
Copy link

codeclimate bot commented Jul 7, 2023

Code Climate has analyzed commit b8045db and detected 0 issues on this pull request.

View more on Code Climate.

@rgonalo
Copy link
Member

rgonalo commented Jan 26, 2024

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.

@KarimJesusGalvez
Copy link
Author

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...)

@KarimJesusGalvez
Copy link
Author

Pending tasks for now:

  1. Restore the original jira upload,
  2. Add the JIRA dependency as optional
  3. command line argument to opt in the new upload method OR maybe introspect installed modules and if installed, use the new one ?

return 0


def create_test_execution(server: JIRA, issueid: str, summary: str,
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add **kwargs for the creation of the dictionary

@KarimJesusGalvez
Copy link
Author

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:

  1. You'll be required to check your own internal names/ids of the fields in the target issue beforehand
  2. You would not be able to create two issue types at the same time ? (as in test execution and bug if failed for example)

@rgonalo
Copy link
Member

rgonalo commented Feb 2, 2024

Pending tasks for now:

  1. Restore the original jira upload,
  2. Add the JIRA dependency as optional
  3. 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

@rgonalo
Copy link
Member

rgonalo commented Feb 2, 2024

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:

  1. You'll be required to check your own internal names/ids of the fields in the target issue beforehand
  2. 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants